On Tue, 5 Sep 2023 17:17:25 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList
> serviceability/sa/TestHeapDumpForInvokeDynamic.java with ZGC.
Marked as reviewed by kevinw (Committer).
Thanks Dan!
-
PR Review:
On Wed, 13 Sep 2023 14:34:42 GMT, Kevin Walls wrote:
> Original failure in 8081569 is a long time ago, and not reproducing.
> Other failures recorded there may be different problems, some of them are
> port related which are helped by other changes since these tests were
> p
On Wed, 13 Sep 2023 14:34:42 GMT, Kevin Walls wrote:
> Original failure in 8081569 is a long time ago, and not reproducing.
> Other failures recorded there may be different problems, some of them are
> port related which are helped by other changes since these tests were
> p
On Thu, 24 Aug 2023 11:34:13 GMT, Kevin Walls wrote:
> Port clashes happening when several tests from test/jdk/sun/tools/jstatd run
> at the same time on the same machine.
>
> There is logic in here for detecting this, but it's not working.
>
> We recently saw this fail
Port clashes happening when several tests from test/jdk/sun/tools/jstatd run at
the same time on the same machine.
There is logic in here for detecting this, but it's not working.
We recently saw this fail with a port in use, and the failure is:
[Jstatd-Thread] Could not bind
d by TCPTransport.java.
> But that is not what we see in this failure.
> Should update its test to check for "Could not bind".
> Should limit the retries also.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision
Original failure in 8081569 is a long time ago, and not reproducing.
Other failures recorded there may be different problems, some of them are port
related which are helped by other changes since these tests were problemlisted.
This problemlist entry should be removed.
-
Commit
This assert happens rarely, but is seen in testing a few times.
getCurrentQueryIndexForProcess comments that it can return -1, but it asserts
that the value is >=0
If we let it return -1 for failure as its comment documents, the caller can
handle the failure and not assert and end the JVM.
On Sat, 2 Sep 2023 00:50:08 GMT, Alex Menkov wrote:
> JDK-8226420 has been closed as a duplicate.
> The fix removes references to 8226420 from problemlist (the tests remain
> problem-listed due other issues).
Marked as reviewed by kevinw (Committer).
-
PR Review:
On Sat, 2 Sep 2023 02:31:54 GMT, ExE Boss wrote:
>> JDK-8226420 has been closed as a duplicate.
>> The fix removes references to 8226420 from problemlist (the tests remain
>> problem-listed due other issues).
>
> test/jdk/ProblemList.txt line 727:
>
>> 725:
On Fri, 8 Sep 2023 10:21:23 GMT, Soumadipta Roy wrote:
>> 8315770: serviceability/sa/TestJmapCoreMetaspace.java should run with
>> -XX:-VerifyDependencies
>>
>> serviceability/sa/TestJmapCoreMetaspace.java runs in hotspot:tier2, and
>> takes about 330 seconds out of 670 seconds of the entire
On Fri, 8 Sep 2023 10:21:23 GMT, Soumadipta Roy wrote:
>> 8315770: serviceability/sa/TestJmapCoreMetaspace.java should run with
>> -XX:-VerifyDependencies
>>
>> serviceability/sa/TestJmapCoreMetaspace.java runs in hotspot:tier2, and
>> takes about 330 seconds out of 670 seconds of the entire
Discovered while testing changes that made this test fail. The test failure is
hard to diagnose as it logs and retries at full speed, possibly forever, until
timeout. This can hit a log file limit. We can save thousands of lines of
text being printed when the test runs normally and
On Thu, 2 Nov 2023 15:47:00 GMT, Serguei Spitsyn wrote:
>> Discovered while testing changes that made this test fail. The test failure
>> is hard to diagnose as it logs and retries at full speed, possibly forever,
>> until timeout. This can hit a log file limit. We can save thousands of
>>
On Wed, 1 Nov 2023 17:10:34 GMT, Kevin Walls wrote:
> Discovered while testing changes that made this test fail. The test failure
> is hard to diagnose as it logs and retries at full speed, possibly forever,
> until timeout. This can hit a log file limit. We can save thousands of
On Thu, 19 Oct 2023 07:54:47 GMT, Kimura Yukihiro wrote:
>> I would like to fix this issue
>> because the test dose not work as intended.
>> Could someone please review it?
>>
>> Thanks,
>> Kimura Yukihiro
>
> Kimura Yukihiro has updated the pull request incrementally with one
> additional
On Mon, 6 Nov 2023 06:55:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this PR which fixes the typos in the method
> javadocs of com.sun.management.OperatingSystemMXBean?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the
> word "betweens" by
On Thu, 7 Sep 2023 02:19:10 GMT, Yi Yang wrote:
>> This patch reduce ~16%(24s->20s) pahse 2 merge time during dumping 32g heap
>> with 96threads and fixes a memory leak of compressor
>>
>> You might argue why this is Linux-only optimization, because sendfile
>> requires at least socket fd in
On Wed, 20 Sep 2023 03:56:28 GMT, Leonid Mesnik wrote:
> Test start failing because of unexpected VM logging.
> The fix is to search expected string ignoring any unknown output from forked
> process.
> Tested with tier1 and by running test with various options used in CI.
Marked as reviewed by
On Tue, 26 Sep 2023 19:28:47 GMT, Chris Plummer wrote:
>> Fine then. Thank you for the explanation.
>
> What was the cause of all the 0's in the output, and how did you get rid of
> them so you could see the assert message?
Thanks Leonid!
On the \u content, I don't see that mess in the
On Wed, 20 Sep 2023 22:08:27 GMT, Leonid Mesnik wrote:
>> This assert happens rarely, but is seen in testing a few times.
>>
>> getCurrentQueryIndexForProcess comments that it can return -1, but it
>> asserts that the value is >=0
>>
>> If we let it return -1 for failure as its comment
On Wed, 27 Sep 2023 10:36:08 GMT, Kevin Walls wrote:
>> What was the cause of all the 0's in the output, and how did you get rid of
>> them so you could see the assert message?
>
> Thanks Leonid!
>
> On the \u content, I don't see that mess in the conso
On Thu, 14 Sep 2023 17:24:39 GMT, Kevin Walls wrote:
> This assert happens rarely, but is seen in testing a few times.
>
> getCurrentQueryIndexForProcess comments that it can return -1, but it asserts
> that the value is >=0
>
> If we let it return -1 for failure as
On Thu, 5 Oct 2023 05:32:20 GMT, Leonid Mesnik wrote:
> Updated test to use createTesJvm.
> Removed internal timeout to not fail when Xcomp is used and also to get more
> info if the test times out.,
>
> Tested by running tier1, hs-tier5 and executing test with various VM flags.
Looks good -
On Fri, 6 Oct 2023 20:47:22 GMT, Leonid Mesnik wrote:
> Test fixed to accept vm flags.
test/jdk/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java line 311:
> 309: private void executeJava() throws Throwable {
> 310: String className =
>From studying test failures, it looks like the way the test identifies its
>related processes is failing.
It checks the mainArgs of a process by attaching, and looks like it
occasionally misses getting a valid match. The hasMainArgs method ignores
exceptions as it is expecting some
On Fri, 6 Oct 2023 20:47:22 GMT, Leonid Mesnik wrote:
> Test fixed to accept vm flags.
Looks good.
So the classPath did not need setting here anyway? I see createTestJvm ends up
adding VM and JAVA options, but I don't see classpath in those. This change
works for me.
Separately I will
On Fri, 6 Oct 2023 19:55:59 GMT, Leonid Mesnik wrote:
> The launcher class is fixed.
> Tested by tier1 and running test with different VM flags
Marked as reviewed by kevinw (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/16079#pullrequestreview-1663928691
can see if this is part of any future failure.
>
> Other small logging changes so we can see more easily the progress through
> the test.
Kevin Walls has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes br
On Fri, 6 Oct 2023 19:10:50 GMT, Kevin Walls wrote:
> From studying test failures, it looks like the way the test identifies its
> related processes is failing.
> It checks the mainArgs of a process by attaching, and looks like it
> occasionally misses getting a valid match. The
On Fri, 20 Oct 2023 13:30:49 GMT, Kevin Walls wrote:
>> From studying test failures, it looks like the way the test identifies its
>> related processes is failing.
>> It checks the mainArgs of a process by attaching, and looks like it
>> occasionally miss
On Fri, 6 Oct 2023 19:10:50 GMT, Kevin Walls wrote:
> From studying test failures, it looks like the way the test identifies its
> related processes is failing.
> It checks the mainArgs of a process by attaching, and looks like it
> occasionally misses getting a valid match. The
On Thu, 5 Oct 2023 16:00:21 GMT, Leonid Mesnik wrote:
> Thank you for your review and feedback. I removed private boolean
> jmxAgentStarted = false; The changes invocations to createTestJvm are needed
> because it added tested flags only.
OK thanks.
I was observing that we want to call
On Mon, 21 Aug 2023 19:54:59 GMT, Chris Plummer wrote:
> ObjectMonitor.object() can be null so we need to defend against it. This bug
> was discovered by code inspection while working on
> [JDK-8280555](https://bugs.openjdk.org/browse/JDK-8280555). We have no test
> for this, and I'm not
On Tue, 22 Aug 2023 23:22:37 GMT, Chris Plummer wrote:
> The CDS archive can change memory locations on different runs of the same JVM
> binary. This exposed a long standing bug in FileMapInfo.java. It was caching
> addresses that could be different for different JVM processes. As a result,
>
On Mon, 21 Aug 2023 21:16:02 GMT, Chris Plummer wrote:
>> VM.buildLongFromIntsPD() is not longer used. Remove it.
>
> Chris Plummer has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - update copyright
> - Remove debugging code
Marked as
On Thu, 24 Aug 2023 18:08:13 GMT, Mark Sheppard wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Less specific error message, could be ports or other failure..
>
> test/jdk/sun/tools/j
also)
> checks for "Port already in use", which can be printed by TCPTransport.java.
>
> Should update its test to check for "Could not bind".
> Should limit the retries also.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last
On Thu, 24 Aug 2023 21:38:41 GMT, Kevin Walls wrote:
>> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>>
>> Port clashes when run at the same time on the same machine have been a
>> problem.
>> The RMI error "no such object in table" ca
On Thu, 24 Aug 2023 11:34:13 GMT, Kevin Walls wrote:
> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>
> Port clashes when run at the same time on the same machine have been a
> problem.
> The RMI error "no such object in table" can mean a reference
On Mon, 28 Aug 2023 19:12:04 GMT, Leonid Mesnik wrote:
> Arguments were added to the launcher arguments.
looks good
-
Marked as reviewed by kevinw (Committer).
PR Review: https://git.openjdk.org/jdk/pull/15454#pullrequestreview-1599925725
On Wed, 8 Nov 2023 08:29:52 GMT, Matthias Baesken wrote:
> On AIX the test
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
> runs into this error:
>
> java.lang.RuntimeException: java.lang.OutOfMemoryError: Metaspace
> at
>
On Tue, 28 Jun 2022 11:21:50 GMT, Kevin Walls wrote:
> Test has been problemlisted for a long time due to intermittent failures.
>
> This is a difficult test as it tries to monitor usage thresholds on Memory
> Pools which are outside its control.
> Not just Java he
On Wed, 6 Jul 2022 22:38:41 GMT, Serguei Spitsyn wrote:
> ...minor questions/comments...
Hi Serguei, yes updated those comments, thanks!
-
PR: https://git.openjdk.org/jdk/pull/9309
> control. Also re-test isExceeded on failure, as fetching the usage and
> isExceeded is a race.
>
> Logging of more pool stats to better understand failures.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Comment update
On Tue, 28 Jun 2022 11:43:42 GMT, Kevin Walls wrote:
>> Test has been problemlisted for a long time due to intermittent failures.
>>
>> This is a difficult test as it tries to monitor usage thresholds on Memory
>> Pools which are outside its control.
>> N
More context in the bug, but there's no evidence that this test should still be
problemlisted.
Adding enableVerbose in the test itself should still keep this trivial: seeing
what actually happened in a test that was once labelled as failing is really
important!
-
Commit messages:
On Fri, 1 Jul 2022 16:12:17 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList sun/tools/jhsdb/JStackStressTest.java on
> linux-aarch64.
Marked as reviewed by kevinw (Committer).
-
PR: https://git.openjdk.org/jdk19/pull/100
> control. Also re-test isExceeded on failure, as fetching the usage and
> isExceeded is a race.
>
> Logging of more pool stats to better understand failures.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Show log output
Test has been problemlisted for a long time due to intermittent failures.
This is a difficult test as it tries to monitor usage thresholds on Memory
Pools which are outside its control.
Not just Java heap pools, where the allocation it makes may or may not affect a
particuclar pool, but
On Tue, 28 Jun 2022 11:43:42 GMT, Kevin Walls wrote:
>> Test has been problemlisted for a long time due to intermittent failures.
>>
>> This is a difficult test as it tries to monitor usage thresholds on Memory
>> Pools which are outside its control.
>> N
On Wed, 29 Jun 2022 09:57:29 GMT, Kevin Walls wrote:
> More context in the bug, but there's no evidence that this test should still
> be problemlisted.
>
> Adding enableVerbose in the test itself should still keep this trivial:
> seeing what actually happened in a test that wa
On Wed, 29 Jun 2022 09:57:29 GMT, Kevin Walls wrote:
> More context in the bug, but there's no evidence that this test should still
> be problemlisted.
>
> Adding enableVerbose in the test itself should still keep this trivial:
> seeing what actually happened in a test that wa
> control. Also re-test isExceeded on failure, as fetching the usage and
> isExceeded is a race.
>
> Logging of more pool stats to better understand failures.
Kevin Walls has updated the pull request with a new target base due to a merge
or a rebase. The pull request now c
On Fri, 24 Jun 2022 00:09:50 GMT, Leonid Mesnik wrote:
> The fix remove JCK-like run, NSK variables and LoadLibrary exception
> handling. The test behavior should remain the same.
>
> The fix is split into several commits, which might be easier for review.
Looks ok to me.
-
On Thu, 16 Jun 2022 00:23:27 GMT, Leonid Mesnik wrote:
> The failure is very intermittent and I wasn't able to reproduce it.
>
> I suspect that the swap might be changed during test execution so I add the
> corresponding check.
>
> If test still fails after fix we should at least exclude
On Mon, 20 Jun 2022 08:08:54 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test only change which updates the
> `DaemonThreadTest` to prevent a NPE when the `jstack` tool launched from the
> test fails with a non-zero exit code?
Marked as reviewed by kevinw (Committer).
On Wed, 29 Jun 2022 09:57:29 GMT, Kevin Walls wrote:
> More context in the bug, but there's no evidence that this test should still
> be problemlisted.
>
> Adding enableVerbose in the test itself should still keep this trivial:
> seeing what actually happened in a test that wa
On Wed, 24 Aug 2022 05:08:40 GMT, Chris Plummer wrote:
>> We currently have no tests for co-located MethodEntry, Step, and Breakpoint
>> events. We should make sure they are being properly co-located as described
>> in the JDI spec, and also do special test cases for
>>
On Thu, 25 Aug 2022 03:31:03 GMT, Chris Plummer wrote:
> SA has the following source directory:
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/proc
>
> However, there are no references to any classes in this directory. There used
> to be a reference to ProcDebuggerLocal, but
On Wed, 24 Aug 2022 20:03:48 GMT, Chris Plummer wrote:
>> In order to help debug
>> [JDK-8292879](https://bugs.openjdk.org/browse/JDK-8292879) failures, turn on
>> class unload tracing in the debuggee and also have the debugger dump all the
>> debuggee output. See the CR for example output.
>
On Tue, 23 Aug 2022 13:59:53 GMT, Matthias Baesken wrote:
> There seems to be a case where EncodingSupport_md.c
> convertUtf8ToPlatformString might leak memory because of a wrong placing of
> free..
Marked as reviewed by kevinw (Committer).
-
PR:
On Thu, 25 Aug 2022 15:15:38 GMT, Chris Plummer wrote:
>> We currently have no tests for co-located MethodEntry, Step, and Breakpoint
>> events. We should make sure they are being properly co-located as described
>> in the JDI spec, and also do special test cases for
>>
On Mon, 29 Aug 2022 20:13:46 GMT, Chris Plummer wrote:
> The page caching support in SA is woefully dated. I think it has stayed the
> same for over 20 years when it was originally done for solarix-x86. This code
> has been replicated for every port. Currently all ports only have a 16mb
>
On Mon, 29 Aug 2022 18:54:58 GMT, Chris Plummer wrote:
> DebuggerBase.writeBytes() is not needed. It is only called by a number of
> other "write" methods, such as writeJBoolean(), but these methods are never
> called, so they can be removed along with writeBytes(). Lastly, writeBytes()
>
On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls wrote:
>> This is test unstable when monitoring CodeHeap pools as they can change
>> outside the test's control.
>> Attempting more heuristics to sense these unrelated changes just means we
>> skip more pools.
>>
>
On Fri, 2 Sep 2022 20:33:37 GMT, David Holmes 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
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
>&g
hread::print_on_error(),
> they aren't connected to the problems seen.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Comment update
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10147/files
- new: https://git.op
On Thu, 25 Aug 2022 19:14:21 GMT, Chris Plummer wrote:
>> We currently have no tests for co-located MethodEntry, Step, and Breakpoint
>> events. We should make sure they are being properly co-located as described
>> in the JDI spec, and also do special test cases for
>>
On Tue, 27 Sep 2022 21:38:43 GMT, Chris Plummer wrote:
> JDK-8293563 is due to a macOS bug (or maybe a feature) that is resulting in
> the java heap not always being present in the core file. Running with
> `-XX:+AlwaysPreTouch` seems to work around this problem. This issue is only
> on
On Tue, 27 Sep 2022 05:16:35 GMT, Chris Plummer wrote:
> Sometimes SA fails to startup with the following error message:
>
> ERROR: failed to workaround classshareing
> Unable to open core file
>
> The code in question is init_classsharing_workaround() in ps_core_common.c.
> There a number of
unnecessary, core/mdmp usually being created in
> the current directory. But getCoreFileLocation() performs Files.move() which
> takes enough time to not be a no-op.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Show file size for dump
unnecessary, core/mdmp usually being created in
> the current directory. But getCoreFileLocation() performs Files.move() which
> takes enough time to not be a no-op.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Reorder loop: success
On Mon, 17 Oct 2022 11:13:55 GMT, Kevin Walls wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just
On Fri, 14 Oct 2022 18:31:24 GMT, Chris Plummer wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just creates a misleading
On Wed, 19 Oct 2022 16:14:16 GMT, Kevin Walls wrote:
>> Set the management.properties
>> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
>> restrict types that can be deserialized.
>>
>> Use the example value from
On Wed, 19 Oct 2022 16:36:35 GMT, Daniel Fuchs wrote:
> Trivially you should probably add `8283093` in the list of bugs that the test
> helps verify. Also I see the test is using `Utils.getFreePort()` which is a
> recipe for intermittent failures (not something you should change here,
>
ers / Filters for JMX), plus Subject
> which is needed when using authentication.
>
> The sun/management tests run OK with this change. The existing test
> sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the
> filter specified is made too restrictive
ers / Filters for JMX), plus Subject
> which is needed when using authentication.
>
> The sun/management tests run OK with this change. The existing test
> sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the
> filter specified is made too restrictive
On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls wrote:
> Set the management.properties
> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
> restrict types that can be deserialized.
>
> Use the example value from the Core Libraries guide (see se
On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls wrote:
>> Set the management.properties
>> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
>> restrict types that can be deserialized.
>>
>> Use the example value from
On Tue, 11 Oct 2022 17:48:30 GMT, Daniel Fuchs wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Additional test with command-line filter setting.
>
> src/jdk.management.agent/share/c
On Mon, 17 Oct 2022 20:16:49 GMT, Kevin Walls wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just
On Fri, 7 Oct 2022 19:54:54 GMT, Kevin Walls wrote:
> There are a few changes we can make to better understand the LingeredApp test
> when it goes wrong:
>
> startAppExactJvmOpts() should not try and call finishApp unless the process
> isAlive, that just creates a misle
On Wed, 19 Oct 2022 17:54:02 GMT, Kevin Walls wrote:
>> Set the management.properties
>> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
>> restrict types that can be deserialized.
>>
>> Use the example value from
On Sat, 22 Oct 2022 03:05:07 GMT, Chris Plummer wrote:
> The implementation of removeThread() is currently:
>
>
> static void
> removeThread(JNIEnv *env, ThreadList *list, jthread thread)
> {
> ThreadNode *node;
>
> node = findThread(list, thread);
> if (node != NULL) {
>
ers / Filters for JMX), plus Subject
> which is needed when using authentication.
>
> The sun/management tests run OK with this change. The existing test
> sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the
> filter specified is made too restrictive
On Tue, 25 Oct 2022 18:16:17 GMT, Serguei Spitsyn wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Additional test with command-line filter setting.
>
> test/jdk/javax/manageme
On Wed, 26 Oct 2022 10:18:28 GMT, Kevin Walls wrote:
>> Set the management.properties
>> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
>> restrict types that can be deserialized.
>>
>> Use the example value from
On Tue, 25 Oct 2022 18:31:29 GMT, Serguei Spitsyn wrote:
> How was this set of segments to be filtered by default identified?
I started with the set of classes given as an example in the Core Libraries
guide,
https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html in
the
On Mon, 17 Oct 2022 19:04:09 GMT, Chris Plummer wrote:
> > ./core.22317 4371398656 bytes
>
> It would be a lot easier to read if this was converted to mb.
OK yes, I'd like both... 8-)
LingeredApp startup took 3119ms
Check for hs_err_pid/core/mdmp files:
./hs_err_pid14641.log 0mb (181706
unnecessary, core/mdmp usually being created in
> the current directory. But getCoreFileLocation() performs Files.move() which
> takes enough time to not be a no-op.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Dump file size in mega
On Fri, 14 Oct 2022 18:37:03 GMT, Chris Plummer wrote:
>> There are a few changes we can make to better understand the LingeredApp
>> test when it goes wrong:
>>
>> startAppExactJvmOpts() should not try and call finishApp unless the process
>> isAlive, that just creates a misleading
On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the
> intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657?
>
> There are two parts to this fix. One is straightforward fix in the test
> configuration
On Tue, 6 Sep 2022 08:42:13 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
>> va
hread::print_on_error(),
> they aren't connected to the problems seen.
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
nits
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10147/files
- new: https://git.openjdk.
On Fri, 9 Sep 2022 18:22:48 GMT, Chris Plummer wrote:
>> Kevin Walls has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify that loop is for checking heap not changing. Exception if
>> continually chang
On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote:
>> Test update to cope with heap size changing (shrinking) in the early life of
>> the test app.
>>
>> A change in GC timing affects this test which reads eden size and heap size.
>> Both eden and heap
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.
>
> Parti
1 - 100 of 588 matches
Mail list logo
