On Sat, 22 Jun 2024 00:18:43 GMT, Coleen Phillimore wrote:
> The 'resolve' for the CLDG iterator was to temporarily keep that CLD from
> being unloaded, in the short time that we're iterating on that particular CLD.
This is the crux of the problem. For concurrent GCs, if the 'resolve' is
On Thu, 20 Jun 2024 16:30:30 GMT, Coleen Phillimore wrote:
> If the default is to not keep the CLD alive, I don't like that we need the
> details of the side effect in the name. Just call it classes_do, etc. I don't
> care about no-keepalive in all these callers, if that's the right answer for
On Wed, 19 Jun 2024 15:06:25 GMT, Axel Boldt-Christmas
wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metadata alive. This is
On Wed, 19 Jun 2024 06:14:21 GMT, Axel Boldt-Christmas
wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metadata alive. This is
On Sat, 15 Jun 2024 16:28:05 GMT, Leonid Mesnik wrote:
>> The vmTestbase/vm/share is a shared test library for vmTestbase tests. This
>> library contains a lot of code that is used by only by small number of tests
>> or not used at all. There are no plans to actively develop new tests in
>>
On Mon, 20 May 2024 07:24:16 GMT, Axel Boldt-Christmas
wrote:
>> Improve `java/util/zip/EntryCount64k.java` stderr parsing by ignoring
>> deprecated warnings. Testing non-generational ZGC requires the use of a
>> deprecated option.
>
> Axel Boldt-Christmas has updated the pull request
On Mon, 20 May 2024 07:22:49 GMT, Axel Boldt-Christmas
wrote:
>> Improve ` java/util/logging/LoggingDeadlock2.java` stderr parsing by
>> ignoring deprecated warnings. Testing non-generational ZGC requires the use
>> of a deprecated option.
>
> Axel Boldt-Christmas has updated the pull request
On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe wrote:
>> MEMFLAGS, as well as its enum constants, should live in its own include.
>>
>> The constants are used throughout the code base, often without needing the
>> allocation APIs exposed through allocation.hpp.
>>
>> The MEMFLAGS enum def
On Mon, 13 May 2024 15:36:13 GMT, Stefan Karlsson wrote:
>> To quote @robehn - Why write a comment for a rule if you can enforce it with
>> code instead...
>
> I tend to agree with that. My earlier question still stands: is there a
> better place to put it? Right now th
On Mon, 13 May 2024 15:26:18 GMT, Daniel D. Daugherty
wrote:
>> Could you instead put the static_assert near the code that will break? Right
>> now it looks obscure and weird to have this check when it is obviously
>> correct as long as no one changes the definition. Would it be enough to
>>
On Mon, 13 May 2024 14:31:22 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/nmt/memflags.cpp line 31:
>>
>>> 29:
>>> 30: // Extra insurance that MEMFLAGS truly has the same size as uint8_t.
>>> 31: STATIC_ASSERT(sizeof(MEMFLAGS) == sizeof(uint8_t));
>>
>> I think you can remove this entire
On Mon, 13 May 2024 04:55:24 GMT, Thomas Stuefe wrote:
>> MEMFLAGS, as well as its enum constants, should live in its own include.
>>
>> The constants are used throughout the code base, often without needing the
>> allocation APIs exposed through allocation.hpp.
>>
>> The MEMFLAGS enum def
On Thu, 2 May 2024 17:23:21 GMT, Aleksey Shipilev wrote:
>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1270:
>>
>>> 1268:
>>> 1269: ParallelScavengeHeap* heap = ParallelScavengeHeap::heap();
>>> 1270: assert(!heap->is_stw_gc_active(), "not reentrant");
>>
>> While reading
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` could then be
On Thu, 2 May 2024 14:40:35 GMT, Aleksey Shipilev wrote:
> `CollectedHeap::is_gc_active()` is confusing, since its name implies _any_ GC
> phase is running, while it actually only covers the STW GCs. It would be good
> to rename it for clarity. The freed-up name, `is_gc_active` could then be
On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson wrote:
> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I
> propose that we stop sending in CodeBlobs to the GCs and make sure to only
> give them nmethods.
>
> I removed `void CodeCache::blobs_do(Cod
On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson wrote:
> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I
> propose that we stop sending in CodeBlobs to the GCs and make sure to only
> give them nmethods.
>
> I removed `void CodeCache::blobs_do(Cod
n. If someone wants to keep this verification in their
> favorite GC I can add calls to this function where we used to call
> CodeCache::blobs_do.
>
> I've only done limited testing and will run extensive testing concurrent with
> the review.
Stefan Karlsson has updated the pul
The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I
propose that we stop sending in CodeBlobs to the GCs and make sure to only give
them nmethods.
I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no more
usage of that function. Is this OK?
I
On Thu, 4 Apr 2024 09:45:58 GMT, Stefan Karlsson wrote:
> We have a few places that uses the terms `KlassObj` and `klassOop` when
> referring to Klasses. This is old code from before the PermGen removal, when
> Klasses also were Java objects.
>
> These names tripped me up whe
On Thu, 4 Apr 2024 12:18:24 GMT, Stefan Karlsson wrote:
>> We have a few places that uses the terms `KlassObj` and `klassOop` when
>> referring to Klasses. This is old code from before the PermGen removal, when
>> Klasses also were Java objects.
>>
>> Th
On Thu, 4 Apr 2024 17:04:30 GMT, Vladimir Kozlov wrote:
>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
>> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
>> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>>
On Thu, 4 Apr 2024 15:56:34 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/gc/shared/gcBehaviours.hpp line 31:
>>
>>> 29: #include "oops/oopsHierarchy.hpp"
>>> 30:
>>> 31: // This is the behaviour for checking if a nmethod is unloading
>>
>> Maybe this should be *an* nmethod?
>
> Quote:
On Thu, 4 Apr 2024 12:13:21 GMT, Roman Kennke wrote:
>> I think it is an old-style TODO. I'm considering if we shouldn't just remove
>> these comments. What do people think about that?
>
> I'm not even sure what they want to say, really. Should be good to remove,
> and if anybody can make
On Thu, 4 Apr 2024 10:07:11 GMT, Roman Kennke wrote:
>> Stefan Karlsson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review Roman
>
> src/hotspot/share/memory/heapInspection.cpp line 173:
>
>&
> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this
> through our lower tiers.
Stefan Karlsson has updated the pull request incrementally with one additional
commit since the last revision:
Review Roman
-
Changes:
- all: https://git.openjdk.org/jdk/pull/186
On Thu, 4 Apr 2024 09:55:38 GMT, Roman Kennke wrote:
>> We have a few places that uses the terms `KlassObj` and `klassOop` when
>> referring to Klasses. This is old code from before the PermGen removal, when
>> Klasses also were Java objects.
>>
>> These names tripped me up when I was reading
We have a few places that uses the terms `KlassObj` and `klassOop` when
referring to Klasses. This is old code from before the PermGen removal, when
Klasses also were Java objects.
These names tripped me up when I was reading the heap heapInspection.cpp and
first though we were mixing the
On Thu, 4 Apr 2024 00:05:20 GMT, Vladimir Kozlov wrote:
>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
>> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
>> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>>
On Wed, 3 Apr 2024 16:38:13 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/code/codeCache.cpp line 1009:
>>
>>> 1007: int CodeCache::nmethod_count() {
>>> 1008: int count = 0;
>>> 1009: for (GrowableArrayIterator heap =
>>> _nmethod_heaps->begin(); heap != _nmethod_heaps->end(); ++heap)
On Wed, 3 Apr 2024 16:29:03 GMT, Vladimir Kozlov wrote:
>> src/hotspot/share/code/codeBlob.hpp line 409:
>>
>>> 407:
>>> 408: // GC/Verification support
>>> 409: virtual void preserve_callee_argument_oops(frame fr, const
>>> RegisterMap *reg_map, OopClosure* f) override { /* nothing to do
On Mon, 1 Apr 2024 21:07:31 GMT, Vladimir Kozlov wrote:
>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
>> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
>> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>>
On Tue, 2 Apr 2024 16:24:19 GMT, Coleen Phillimore wrote:
>> Remove the notproduct distinction for command line options, rather than
>> trying to wrestle the macros to fix the bug that they've been treated as
>> develop options for some time now. This simplifies the command line option
>>
On Wed, 13 Mar 2024 20:10:25 GMT, Roger Riggs wrote:
>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect
>> assumption about GC behavior and a race condition.
>>
>> Removed test based on incorrect assumptions about simultaneous clearing of
>> WeakReferences.
>>
On Wed, 13 Mar 2024 19:41:25 GMT, Roger Riggs wrote:
>> The intermittent failure of ObjectStreamClassCaching is due to an incorrect
>> assumption about GC behavior and a race condition.
>>
>> Removed test based on incorrect assumptions about simultaneous clearing of
>> WeakReferences.
>>
On Tue, 12 Mar 2024 06:15:20 GMT, David Holmes wrote:
> GC folk should be reviewing this not runtime.
I don't fully agree with that. How these serviceability tools work, and their
interfaces, are usually not something that we GC devs are directly responsible
for. This change could be reviewed
On Tue, 13 Feb 2024 11:05:30 GMT, Magnus Ihse Bursie wrote:
>> There are several places in hotspot where an internal function should have
>> been declared static, but isn't.
>>
>> These were discovered by trying to use the gcc option
>> `-Wmissing-declarations` and the corresponding clang
On Mon, 12 Feb 2024 12:43:09 GMT, Magnus Ihse Bursie wrote:
> There are several places in hotspot where an internal function should have
> been declared static, but isn't.
>
> These were discovered by trying to use the gcc option
> `-Wmissing-declarations` and the corresponding clang option
On Fri, 9 Feb 2024 05:31:17 GMT, Yifeng Jin wrote:
>> These two files (`GCCause.java` and `gcCause.hpp`) should be in sync by
>> design, see comments in these two files. However, some recent changes (e.g.
>> [JDK-8240239](https://bugs.openjdk.org/browse/JDK-8240239)) to `gcCause.hpp`
>> were
On Thu, 8 Feb 2024 06:19:16 GMT, Yifeng Jin wrote:
> These two files (`GCCause.java` and `gcCause.hpp`) should be in sync by
> design, see comments in these two files. However, some recent changes (e.g.
> [JDK-8240239](https://bugs.openjdk.org/browse/JDK-8240239)) to `gcCause.hpp`
> were not
On Tue, 23 Jan 2024 10:20:46 GMT, Albert Mingkun Yang wrote:
> Trivial removing redundant code.
Marked as reviewed by stefank (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17530#pullrequestreview-1838769192
we find
> this output to be too noisy.
Stefan Karlsson has updated the pull request incrementally with one additional
commit since the last revision:
Update copyright years
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16807/files
- new: https://git.openjdk.org/jdk
On Fri, 12 Jan 2024 01:10:49 GMT, Leonid Mesnik wrote:
> Needed to update copyrights now.
Even when the code was written in 2023?
-
PR Comment: https://git.openjdk.org/jdk/pull/16807#issuecomment-1888699636
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jd
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
This pull request has now been integrated.
Changeset: ec385057
Author:
TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file
still has a reference to it. This causes problems in our CI pipeline.
-
Commit messages:
- Revert unrelated changes
- 8323508: Remove TestGCLockerWithShenandoah.java line from TEST.groups
Changes:
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
Thanks. The unrelated change has been reverted.
-
PR Comment:
On Fri, 5 Jan 2024 08:22:41 GMT, Stefan Karlsson wrote:
>> Most functions in ProcessTools are declared to throw Exceptions, or one of
>> its subclasses. However, there are a small number of functions that are
>> unnecessarily declared to throw Throwable instead of Ex
On Wed, 3 Jan 2024 09:51:24 GMT, Stefan Karlsson wrote:
> Most functions in ProcessTools are declared to throw Exceptions, or one of
> its subclasses. However, there are a small number of functions that are
> unnecessarily declared to throw Throwable instead of Exception. I propose
we find
> this output to be too noisy.
Stefan Karlsson has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Merge remote-tracking branch 'upstream/master' into
8320699_OutputAnalyzer_progress_logging
- Update OutputBu
On Fri, 5 Jan 2024 02:22:45 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Please help review this patch that fixes the failures of
>> FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>>
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional
> commit
ow Exception.
>
> This is a trivial patch to make it easier to refactor tests to use the
> updated functions.
>
> Tested manually, but will wait for GHA to verify that the change is OK.
Stefan Karlsson has updated the pull request incrementally with one additional
commit since the last
On Thu, 4 Jan 2024 11:56:45 GMT, David Holmes wrote:
> > For this test I think we can just add @requires vm.gc.Serial
>
> @stefank but it doesn't require that, it explicitly sets that. The test
> requires that no specific GC has been requested.
@dholmes-ora `@requires vm.gc.Serial` doesn't
On Thu, 4 Jan 2024 08:01:57 GMT, Denghui Dong wrote:
> Hi,
>
> Please help review this patch that fixes the failures of
> FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>
> Thanks.
I prefer if we stay away from using `@requires vm.flagless` if possible. For
this test I think
Most functions in ProcessTools are declared to throw Exceptions, or one of its
subclasses. However, there are a small number of functions that are
unnecessarily declared to throw Throwable instead of Exception. I propose that
we change them to also be declared to throw Exception.
This is a
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
> proces
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
> proces
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
> proces
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
> proces
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson wrote:
> There is some logging printed when tests spawns processes. This logging is
> triggered from calls to `OutputAnalyzer`, when it delegates calls to
> `LazyOutputBuffer`.
>
> If we write code like this:
>
&
On Mon, 11 Dec 2023 14:06:43 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
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
On Mon, 11 Dec 2023 14:06:43 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
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
On Mon, 11 Dec 2023 14:06:43 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
On Mon, 11 Dec 2023 14:06:43 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
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request with a n
On Tue, 12 Dec 2023 09:01:08 GMT, Stefan Karlsson wrote:
>> There is some logging printed when tests spawns processes. This logging is
>> triggered from calls to `OutputAnalyzer`, when it delegates calls to
>> `LazyOutputBuffer`.
>>
>> If we write code like
for process
> 2547719
>
> testExecuteProcessStdout
> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for process
>
On Wed, 20 Dec 2023 21:11:09 GMT, Kim Barrett wrote:
> I'm not a fan of the additional clutter in APIs that the static memory types
> add. If we had a variant of GrowableArrayCHeap that was not itself
> dynamically allocatable and took a memory type to use internally as a
> constructor
for process
> 2547719
>
> testExecuteProcessStdout
> [2023-12-11T11:05:44.049509860Z] Gathering output for process 2547741
> [2023-12-11T11:05:46.227768897Z] Waiting for completion for process 2547741
> [2023-12-11T11:05:46.228021173Z] Waiting for completion finished for process
On Tue, 12 Dec 2023 07:43:31 GMT, David Holmes wrote:
>> Stefan Karlsson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Typo
>
> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 111:
>
>&g
On Mon, 11 Dec 2023 11:16:05 GMT, Stefan Karlsson wrote:
> There is some logging printed when tests spawns processes. This logging is
> triggered from calls to `OutputAnalyzer`, when it delegates calls to
> `LazyOutputBuffer`.
>
> If we write code like this:
>
&
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request increme
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request increme
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request increme
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request increme
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request incrementally wi
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request incrementally wi
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request incrementally wi
e that we name this functions using the same naming scheme we used
> for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`.
> That is, we change `executeTestJvm` to `executeTestJava` and add a new
> `executeLimitedTestJava` function.
Stefan Karlsson has updated the pull request incrementally wi
There is some logging printed when tests spawns processes. This logging is
triggered from calls to `OutputAnalyzer`, when it delegates calls to
`LazyOutputBuffer`.
If we write code like this:
ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
OutputAnalyzer output = new
[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 now have `createTestJavaProcessBuilder` and
[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 now have `createTestJavaProcessBuilder` and
[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 now have `createTestJavaProcessBuilder` and
[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 now have `createTestJavaProcessBuilder` and
On Wed, 6 Dec 2023 01:56:46 GMT, David Holmes wrote:
> FWIW exitCode out numbers exitValue in source code 3:1 (and > 5:1 in test
> code).
That might be the case, but both the called function returning the value and
the function we are changing uses the name exitValue. It seems irrelevant that
On Fri, 1 Dec 2023 12:44:17 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in
On Fri, 1 Dec 2023 11:14:04 GMT, Jaikiran Pai wrote:
>> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
>>
>>> 148: @Override
>>> 149: public int getExitValue() {
>>> 150: Integer exitCode = this.processExitCode;
>>
>> Do we really need the local `exitCode` variable?
On Fri, 1 Dec 2023 11:09:30 GMT, Stefan Karlsson wrote:
>> Can I please get a review for this change to the test library's
>> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
>> from the `getExitValue()` call?
>>
>> As noted in https
On Fri, 1 Dec 2023 09:48:23 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change to the test library's
> `OutputAnalyzer` class, which proposes to remove some unnecessary logging
> from the `getExitValue()` call?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8321163,
On Thu, 30 Nov 2023 12:19:33 GMT, Jaikiran Pai wrote:
> Hello Stefan,
>
> > The test were I want to use this is a long-running stress test that is
> > known to be good at shaking out JVM hangs. It has been written to provide
> > its own output about spawned processes and what they are doing,
we find
> this output to be too noisy.
Stefan Karlsson has updated the pull request incrementally with one additional
commit since the last revision:
Update OutputBuffer.java copyright years
-
Changes:
- all: https://git.openjdk.org/jdk/pull/16807/files
- new: https://
On Wed, 22 Nov 2023 15:00:29 GMT, Stefan Karlsson wrote:
> In the rewrites made for:
> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>
> I removed the filtering of *owned ObjectMonitors wi
On Wed, 29 Nov 2023 06:38:51 GMT, Stefan Karlsson wrote:
>> In the rewrites made for:
>> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump
>> asserts in interleaved ObjectMonitor::deflate_monitor calls`
>>
>> I removed the filtering of *
1 - 100 of 667 matches
Mail list logo
