Re: RFR: 8315097: Rename createJavaProcessBuilder [v3]

2023-08-30 Thread Stefan Karlsson
On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of >> createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed >> -i -e >>

Re: RFR: 8318447: Move NMT source code to own subdirectory [v7]

2023-10-25 Thread Stefan Karlsson
On Tue, 24 Oct 2023 11:51:45 GMT, Johan Sjölen wrote: >> I think that NMT is deserving of its own subdirectory. Can we do a review of >> the changes before I fix the merge conflicts? >> >> 1. Moved all the nmt source code from services/ to nmt/ >> 2. Renamed all the include statements and

Re: RFR: 8318447: Move NMT source code to own subdirectory [v8]

2023-10-26 Thread Stefan Karlsson
On Thu, 26 Oct 2023 09:51:15 GMT, Johan Sjölen wrote: >> I think that NMT is deserving of its own subdirectory. Can we do a review of >> the changes before I fix the merge conflicts? >> >> 1. Moved all the nmt source code from services/ to nmt/ >> 2. Renamed all the include statements and

Re: RFR: 8315097: Rename createJavaProcessBuilder [v3]

2023-10-25 Thread Stefan Karlsson
On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs wrote: >> I have created an alternative that uses enums to force the user to make a >> decision: >> https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools >> . Another alternative is to do the same but instead using an enum (I

Re: RFR: 8315880: change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT

2023-09-19 Thread Stefan Karlsson
On Mon, 18 Sep 2023 20:47:13 GMT, Daniel D. Daugherty wrote: > Change the default of LockingMode to LM_LIGHTWEIGHT from LM_LEGACY. > > This fix has been tested with 3 Mach5 Tier[1-8] runs and a 4th is in process. Looks good. Thank you! - Marked as reviewed by stefank (Reviewer).

Re: RFR: 8318447: Move NMT source code to own subdirectory

2023-10-20 Thread Stefan Karlsson
On Thu, 19 Oct 2023 20:06:50 GMT, Johan Sjölen wrote: > I think that NMT is deserving of its own subdirectory. Can we do a review of > the changes before I fix the merge conflicts? > > 1. Moved all the nmt source code from services/ to nmt/ > 2. Renamed all the include statements and sorted

Re: RFR: 8318447: Move NMT source code to own subdirectory

2023-10-23 Thread Stefan Karlsson
On Fri, 20 Oct 2023 11:31:11 GMT, Johan Sjölen wrote: > For the gtest source files I separated the includes in a consistent manner, > they all look like this pattern now: That's not what I see in the latest patch. Could you revert that separation and then we can consider that style change in

Re: RFR: 8318447: Move NMT source code to own subdirectory [v6]

2023-10-23 Thread Stefan Karlsson
On Mon, 23 Oct 2023 08:34:59 GMT, Johan Sjölen wrote: >> I think that NMT is deserving of its own subdirectory. Can we do a review of >> the changes before I fix the merge conflicts? >> >> 1. Moved all the nmt source code from services/ to nmt/ >> 2. Renamed all the include statements and

Re: RFR: 8318447: Move NMT source code to own subdirectory [v5]

2023-10-23 Thread Stefan Karlsson
On Fri, 20 Oct 2023 12:49:46 GMT, Johan Sjölen wrote: >> I think that NMT is deserving of its own subdirectory. Can we do a review of >> the changes before I fix the merge conflicts? >> >> 1. Moved all the nmt source code from services/ to nmt/ >> 2. Renamed all the include statements and

Re: RFR: 8315097: Rename createJavaProcessBuilder [v6]

2023-10-24 Thread Stefan Karlsson
On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth wrote: >> Rename createJavaProcessBuilder so that it is not used by mistake instead of >> createTestJvm. >> >> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed >> -i -e >>

Re: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method [v2]

2023-08-25 Thread Stefan Karlsson
On Fri, 25 Aug 2023 09:45:09 GMT, Johan Sjölen wrote: >> This code looks similar to a capturing lambda. Would an alternative be to >> use that instead and let the calling code be changed to: >> >> >> int i = lgrp_spaces()->find([&](LGRPSpace* space) { >> return space->lgrp_id() ==

Re: RFR: 8314502: Change the comparator taking version of GrowableArray::find to be a template method

2023-08-25 Thread Stefan Karlsson
On Fri, 25 Aug 2023 08:31:58 GMT, Johan Sjölen wrote: >> src/hotspot/share/utilities/growableArray.hpp line 213: >> >>> 211: >>> 212: template >>> 213: int find(T* token, bool f(T*, E)) const { >> >> Pardon my ignorance here, but what is the type relationship between T and E? > > It's

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]

2022-06-27 Thread Stefan Karlsson
On Mon, 27 Jun 2022 14:14:23 GMT, Stefan Karlsson wrote: >>> The current approach limits the knowledge of non-strong ref types to >>> `instanceRefKlass` file. >> >> The mechanism used to compute the correct reftype is purely derived from the >> parser,

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]

2022-06-27 Thread Stefan Karlsson
On Fri, 24 Jun 2022 00:15:10 GMT, Kim Barrett wrote: >> `_reference_type` always gets the correct value after the constructor is >> run. The member initializer list just follows the convention of having all >> fields set. One could move this field inside the constructor body to ensure >> this

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v10]

2022-06-29 Thread Stefan Karlsson
On Tue, 28 Jun 2022 19:43:33 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with four > additional commits since the last revision: > > - arg rename > - default arg > - revert >

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v9]

2022-06-28 Thread Stefan Karlsson
On Mon, 27 Jun 2022 22:19:35 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one > additional commit since the last revision: > > review Looks good. +1 on Kim's latest

Re: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v9]

2022-06-28 Thread Stefan Karlsson
On Mon, 27 Jun 2022 22:19:35 GMT, Albert Mingkun Yang wrote: >> Simple rename and some comments update. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one > additional commit since the last revision: > > review Scratch my last comment. This

RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT

2022-09-02 Thread Stefan Karlsson
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: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT

2022-09-07 Thread Stefan Karlsson
On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > 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 s

Re: RFR: 8295475: Move non-resource allocation strategies out of ResourceObj [v2]

2022-10-18 Thread Stefan Karlsson
used the name AnyObj, as short, simple > name. I'm open to changing the name to something else. > > The patch also adds a new class named ArenaObj, which is for objects only > allocated in provided arenas. > > The patch also removes the need to provide ResourceObj/AnyObj::C_HEAP to &g

RFR: 8295475: Move non-resource allocation strategies out of ResourceObj

2022-10-18 Thread Stefan Karlsson
Background to this patch: This prototype/patch has been discussed with a few HotSpot devs, and I've gotten feedback that I should send it out for broader discussion/review. It could be a first step to make it easier to talk about our allocation super classes and strategies. This in turn would

Re: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2]

2022-09-08 Thread Stefan Karlsson
On Thu, 8 Sep 2022 08:42:30 GMT, Stefan Karlsson wrote: >> 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 th

Integrated: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT

2022-09-08 Thread Stefan Karlsson
On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > 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 s

Re: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2]

2022-09-08 Thread Stefan Karlsson
On Wed, 7 Sep 2022 22:06:11 GMT, Kim Barrett wrote: > Looks good. Thanks. > Also noticed some pre-existing unnecessary (void*) casts of the pointer > argument to p2i. Not your problem, and not really appropriate for this change > to do anything about them, but I really hate eye-catching

Re: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v7]

2022-10-06 Thread Stefan Karlsson
On Thu, 6 Oct 2022 12:44:23 GMT, Johan Sjölen wrote: >> Here's a suggested solution for the ticket mentioned and a use case for >> outputStream. I'm not attached to the name. >> >> This saves space for all allocated outputStreams, which is nice. It also >> makes the purpose of ResourceObj

Re: RFR: 8299853: Serial: Use more concrete type for TenuredGeneration::_the_space

2023-01-10 Thread Stefan Karlsson
On Tue, 10 Jan 2023 10:51:14 GMT, Albert Mingkun Yang wrote: > Simple change of using the actual type for a field. > > Test: hotspot_gc Looks good. Some nits: src/hotspot/share/gc/serial/tenuredGeneration.hpp line 68: > 66: void assert_correct_size_change_locking(); > 67: > 68:

Re: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4]

2023-01-11 Thread Stefan Karlsson
On Tue, 10 Jan 2023 22:50:11 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of >> `MmapArrayAllocator` have been switched to normal `malloc`. The >> justification is that none of the code paths are called from signal >> handlers, so using `mmap`

Re: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v4]

2023-01-11 Thread Stefan Karlsson
On Wed, 11 Jan 2023 14:27:44 GMT, Justin King wrote: > ArrayAllocator with ArrayAllocatorMallocLimit removed is effectively > MallocArrayAllocator. Are you suggesting leaving MallocArrayAllocator and > MmapArrayAllocator thus update references to ArrayAllocator to be > MallocArrayAllocator?

Re: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v7]

2023-01-11 Thread Stefan Karlsson
On Wed, 11 Jan 2023 20:53:38 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of >> `MmapArrayAllocator` have been switched to normal `malloc`. The >> justification is that none of the code paths are called from signal >> handlers, so using `mmap`

Re: RFR: 8298241: Replace C-style casts with JavaThread::cast

2022-12-14 Thread Stefan Karlsson
On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes wrote: > This is a simple cleanup RFE to get rid of old-style C casts in relation to > JavaThread. > > In many cases involving NULL/nullptr the cast could just be dropped. > Sometimes a static cast is needed to disambiguate overloads. > > A

Re: RFR: 8298264: Merge OffsetTableContigSpace into TenuredSpace

2022-12-14 Thread Stefan Karlsson
On Wed, 7 Dec 2022 11:16:03 GMT, Albert Mingkun Yang wrote: > Small change of merging two classes to reduce inheritance chain length. > > Test: hotspot_gc Marked as reviewed by stefank (Reviewer). - PR: https://git.openjdk.org/jdk/pull/11556

Re: RFR: 8296886: Fix various include sort order issues [v3]

2022-11-24 Thread Stefan Karlsson
r the include headers I've also cleaned up surrounding > whitespaces and incorrect include guards. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge remote-tracking branch 'upstream/master' into

Re: RFR: 8296886: Fix various include sort order issues [v2]

2022-11-24 Thread Stefan Karlsson
On Wed, 16 Nov 2022 16:17:48 GMT, Stefan Karlsson wrote: >> The sorted blocks of includes have deteriorated to the point that I felt >> compelled to clean up some of the issues. >> >> *EDIT*: The below discussion has been deferred out of this PR. Now this on

Integrated: 8296886: Fix various include sort order issues

2022-11-24 Thread Stefan Karlsson
On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson wrote: > The sorted blocks of includes have deteriorated to the point that I felt > compelled to clean up some of the issues. > > *EDIT*: The below discussion has been deferred out of this PR. Now this only > deals with fixin

Re: RFR: 8296886: Fix various include sort order issues [v2]

2022-11-16 Thread Stefan Karlsson
; src/hotspot/share, just like the other platform-independent headers in HotSpot. > > While going over the include headers I've also cleaned up surrounding > whitespaces and incorrect include guards. Stefan Karlsson has updated the pull request with a new target base due to a me

Re: RFR: 8296926: Sort include lines of files in the include/ directory [v4]

2022-11-16 Thread Stefan Karlsson
> the header files in src/hotspot/share/include gets included by specifying the > path from src/hotspot/share, just like the other platform-independent headers > in HotSpot . > > This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that > those changes can be

Re: RFR: 8296926: Sort include lines of files in the include/ directory [v4]

2022-11-16 Thread Stefan Karlsson
On Wed, 16 Nov 2022 11:05:59 GMT, Stefan Karlsson wrote: >> One of the more prevalent issues is that files in src/hotspot/share/include >> are not properly sorted. There has been some discussion that that was done >> on purpose, but it just adds another exception to

Integrated: 8296926: Sort include lines of files in the include/ directory

2022-11-16 Thread Stefan Karlsson
On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson wrote: > One of the more prevalent issues is that files in src/hotspot/share/include > are not properly sorted. There has been some discussion that that was done on > purpose, but it just adds another exception to the include rules t

Re: RFR: 8296886: Fix various include sort order issues [v2]

2022-11-17 Thread Stefan Karlsson
On Fri, 11 Nov 2022 21:01:31 GMT, Kim Barrett wrote: >> 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: >> >> - Cleanups >> - Merge remote-tr

Re: RFR: 8296886: Fix various include sort order issues [v2]

2022-11-17 Thread Stefan Karlsson
On Mon, 14 Nov 2022 11:39:10 GMT, Kim Barrett wrote: >> src/hotspot/os/windows/jvm_windows.cpp line 27: >> >>> 25: #include "precompiled.hpp" >>> 26: #include "include/jvm.h" >>> 27: #include "os_windows.hpp" >> >> os_windows should be at the end, included using `OS_HEADER("os")`. > > But

Re: RFR: 8296886: Fix various include sort order issues [v2]

2022-11-17 Thread Stefan Karlsson
On Wed, 16 Nov 2022 16:17:48 GMT, Stefan Karlsson wrote: >> The sorted blocks of includes have deteriorated to the point that I felt >> compelled to clean up some of the issues. >> >> One of the more prevalent issues is that files in src/hotspot/share/include &g

Re: RFR: 8296926: Use proper include lines for files in include/ [v3]

2022-11-15 Thread Stefan Karlsson
> the header files in src/hotspot/share/include gets included by specifying the > path from src/hotspot/share, just like the other platform-independent headers > in HotSpot . > > This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that > those changes can be

Re: RFR: JDK-8301070: Replace NULL with nullptr in share/memory/

2023-01-26 Thread Stefan Karlsson
On Wed, 25 Jan 2023 11:45:47 GMT, Johan Sjölen wrote: > Do the conversion in the share/memory/ sub-directory and all of its files. Marked as reviewed by stefank (Reviewer). src/hotspot/share/memory/guardedMemory.hpp line 196: > 194:*/ > 195: void* wrap_with_guards(void* base_ptr, size_t

RFR: 8296776: Stop using mtNone as marker for CHeap allocations in GrowableArray

2022-11-10 Thread Stefan Karlsson
Today we use mtNone to denote that a GrowableArray should *NOT* be backed by a CHeap allocated array. I've gotten feedback that it would probably be good to limit the usage of mtNone, and at some point maybe completely remove it. This patch takes a small step to remove mtNone from the

Re: RFR: 8296886: Fix various include sort order issues

2022-11-14 Thread Stefan Karlsson
On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson wrote: > The sorted blocks of includes have deteriorated to the point that I felt > compelled to clean up some of the issues. > > One of the more prevalent issues is that files in src/hotspot/share/include > are not properly so

Re: RFR: 8296886: Fix various include sort order issues

2022-11-14 Thread Stefan Karlsson
On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson wrote: > The sorted blocks of includes have deteriorated to the point that I felt > compelled to clean up some of the issues. > > One of the more prevalent issues is that files in src/hotspot/share/include > are not properly so

RFR: 8296926: Use proper include lines for files in include/

2022-11-14 Thread Stefan Karlsson
One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds another exception to the include rules that don't have any practical purposes, IMHO. It also goes against our

Re: RFR: 8296875: Generational ZGC: Refactor loom code [v2]

2022-11-14 Thread Stefan Karlsson
On Mon, 14 Nov 2022 10:15:41 GMT, Erik Österlund wrote: >> The current loom code makes some assumptions about GC that will not work >> with generational ZGC. We should make this code more GC agnostic, and >> provide a better interface for talking to the GC. >> >> In particular, >> 1) All GCs

Re: RFR: 8296926: Use proper include lines for files in include/

2022-11-14 Thread Stefan Karlsson
On Mon, 14 Nov 2022 09:25:11 GMT, Stefan Karlsson wrote: > One of the more prevalent issues is that files in src/hotspot/share/include > are not properly sorted. There has been some discussion that that was done on > purpose, but it just adds another exception to the include rules t

Re: RFR: 8296926: Use proper include lines for files in include/ [v2]

2022-11-15 Thread Stefan Karlsson
> the header files in src/hotspot/share/include gets included by specifying the > path from src/hotspot/share, just like the other platform-independent headers > in HotSpot . > > This RFE splits out the 'include/' changes from #11108 / JDK-8296886, so that > those changes can be

Re: RFR: 8296926: Use proper include lines for files in include/ [v2]

2022-11-15 Thread Stefan Karlsson
On Tue, 15 Nov 2022 14:25:15 GMT, Erik Joelsson wrote: > Build change looks good. Thanks, Erik. Actually, that change should have been reverted with the last change. I'll revert that. - PR: https://git.openjdk.org/jdk/pull/11133

RFR: 8296886: Fix various include sort order issues

2022-11-11 Thread Stefan Karlsson
The sorted blocks of includes have deteriorated to the point that I felt compelled to clean up some of the issues. One of the more prevalent issues is that files in src/hotspot/share/include are not properly sorted. There has been some discussion that that was done on purpose, but it just adds

Re: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path

2023-04-24 Thread Stefan Karlsson
On Mon, 24 Apr 2023 08:24:53 GMT, Kim Barrett wrote: > Please review this change to the string deduplication thread to make it a kind > of JavaThread rather than a ConcurrentGCThread. There are several pieces to > this change: > > (1) New class StringDedupThread (derived from JavaThread),

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-11 Thread Stefan Karlsson
On Tue, 11 Apr 2023 11:47:46 GMT, Roman Kennke wrote: >> src/hotspot/share/runtime/lockStack.inline.hpp line 111: >> >>> 109: int end = to_index(_top); >>> 110: for (int i = end - 1; i >= 0; i--) { >>> 111: if (NativeAccess<>::oop_load(&_base[i]) == o) { >> >> The use of NativeAccess

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-11 Thread Stefan Karlsson
On Thu, 6 Apr 2023 11:59:45 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current >> stack-locking implementation. It retains the advantages of stack-locking >> (namely fast locking in uncontended code-paths), while avoiding the overload >> of the

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-11 Thread Stefan Karlsson
On Tue, 11 Apr 2023 13:48:15 GMT, Roman Kennke wrote: >> It looks to me like the code could read racingly read the element just above >> `_top`, which could contain a stale oop. If the address of the stale oop >> matches the address of `o` then `contains` would incorrectly return true. >> >>

Re: RFR: 8291555: Implement alternative fast-locking scheme [v56]

2023-04-11 Thread Stefan Karlsson
On Wed, 12 Apr 2023 02:08:08 GMT, David Holmes wrote: >> That seems fine to me, as long as we don't crash. But my understanding is >> that Generational ZGC will crash if it sees a stale oop. Isn't it possible >> that the racing read sees junk that looks to Generational ZGC like a stale >>

Re: RFR: JDK-8301983: Refactor MEMFLAGS and AllocFailStrategy [v5]

2023-02-14 Thread Stefan Karlsson
On Tue, 7 Feb 2023 17:25:02 GMT, Justin King wrote: >> - Rename `MEMFLAGS` to `MemoryType`. `MEMFLAGS` is highly misleading as >> flags typically can be combined. >> - Update `MemoryType` to have enumeration names that follow the style guide, >> no `mt` prefix. >> - Create aliases for old

Re: RFR: 8307058: Implementation of Generational ZGC [v2]

2023-05-03 Thread Stefan Karlsson
On Wed, 3 May 2023 18:52:19 GMT, Chris Plummer wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix PPC build after 8305668 > > test/hotspot/jtreg/ProblemList-generational-zgc.txt

Re: RFR: 8307058: Implementation of Generational ZGC [v5]

2023-05-03 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle'

Re: RFR: 8307058: Implementation of Generational ZGC [v3]

2023-05-03 Thread Stefan Karlsson
On Wed, 3 May 2023 21:32:54 GMT, Martin Doerr wrote: > I'm getting build warnings on all linux platforms with gcc-11.3.0: > > ``` > src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library, > "minor" is defined > by . For historical compatibility, it is > currently defined by

Re: RFR: 8307058: Implementation of Generational ZGC [v4]

2023-05-03 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle

Re: RFR: 8307058: Implementation of Generational ZGC [v2]

2023-05-03 Thread Stefan Karlsson
On Wed, 3 May 2023 18:57:22 GMT, Chris Plummer wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix PPC build after 8305668 > > test/jdk/com/sun/jdi/ThreadMemoryLeakTest.ja

Re: RFR: 8307058: Implementation of Generational ZGC [v2]

2023-05-03 Thread Stefan Karlsson
On Wed, 3 May 2023 20:00:42 GMT, Chris Plummer wrote: >> Yes, the test was finicky with the heap size. Given that the leak it tries >> to provoke would be provoked by other GCs as well, we didn't think it was >> that important to run this particular test with Generational ZGC. If you >> still

Re: RFR: 8307058: Implementation of Generational ZGC [v3]

2023-05-03 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's >

Re: RFR: 8307058: Implementation of Generational ZGC [v2]

2023-05-03 Thread Stefan Karlsson
On Wed, 3 May 2023 18:54:24 GMT, Chris Plummer wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix PPC build after 8305668 > > test/jdk/ProblemList-generational-zgc.txt line

RFR: 8307428: jstat tests doesn't tolerate dash in the O column

2023-05-04 Thread Stefan Karlsson
When running jstat tests like the following: test/jdk/sun/tools/jstatd/TestJstatdServer.java with Generational ZGC we get a failure because the O (old generation percentage) is reported as `-` and not a number. The reason why it is reported as `-` is that the current capacity of the old

Re: RFR: 8307058: Implementation of Generational ZGC [v6]

2023-05-04 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's

Re: RFR: 8307058: Implementation of Generational ZGC [v2]

2023-05-04 Thread Stefan Karlsson
On Wed, 3 May 2023 21:08:39 GMT, Stefan Karlsson wrote: >> test/jdk/ProblemList-generational-zgc.txt line 27: >> >>> 25: # >>> 26: # List of quarantined tests for testing with Generational ZGC. >>> 27: # >> >> Are the tests in `test/j

Re: RFR: 8307428: jstat tests doesn't tolerate dash in the O column

2023-05-04 Thread Stefan Karlsson
On Thu, 4 May 2023 09:52:25 GMT, Thomas Schatzl wrote: > Is it possible to remove the G1 hack in this change too? Because since now a > zero value is supported in the output, there does not seem to be a reason to > keep it for G1. I prefer if that is done and tested as a separate PR.

Re: RFR: 8309044: Replace NULL with nullptr, final sweep of hotspot code

2023-05-29 Thread Stefan Karlsson
On Mon, 29 May 2023 10:09:15 GMT, Johan Sjölen wrote: > A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes > I'd appreciate if this was considered trivial. Looks good. Though, I'd prefer if we could slightly tweak the following two print lines.

Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v4]

2023-06-02 Thread Stefan Karlsson
On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >>

Re: RFR: 8299915: Remove ArrayAllocatorMallocLimit and associated code [v10]

2023-05-22 Thread Stefan Karlsson
On Thu, 19 Jan 2023 17:23:19 GMT, Justin King wrote: >> Remove abstraction that is a holdover from Solaris. Direct usages of >> `MmapArrayAllocator` have been switched to normal `malloc`. The >> justification is that none of the code paths are called from signal >> handlers, so using `mmap`

Re: RFR: 8309408: Thread.sleep cleanup

2023-06-05 Thread Stefan Karlsson
On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman wrote: > Thread.sleep has had quite a bit of churn recently to support virtual > threads, add sleep(Duration), a JFR event, and the change the underlying > implementation to support sub-millis precision. I think the changes have > settled down now

Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental)

2023-06-01 Thread Stefan Karlsson
On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen wrote: > OpenJDK Colleagues: > > Please review this proposed integration of Generational mode for Shenandoah > GC under https://bugs.openjdk.org/browse/JDK-8307314. > > Generational mode of Shenandoah is enabled by adding >

Re: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

2023-06-16 Thread Stefan Karlsson
On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson wrote: > Generational ZGC changed the location where the heap object iterator called > the visit function. It used to be called when the objects were popped and > then followed, but it was changed so that the function whe

RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

2023-06-16 Thread Stefan Karlsson
Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the

Re: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]

2023-06-16 Thread Stefan Karlsson
On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas wrote: >> The current implementation for testing generational ZGC with jtreg is >> implemented with a filter on the mode flag `ZGenerational`. Because of this >> only environments which set this flag explicitly will run most of the tests.

Re: RFR: 8310906: Fix -Wconversion warnings in runtime, oops and some code header files. [v3]

2023-06-28 Thread Stefan Karlsson
On Tue, 27 Jun 2023 15:11:34 GMT, Coleen Phillimore wrote: >> Hm. Maybe this would be ok. Our original idea was to make it T* not T until >> this cast. I don't know how many other cases there are that I haven't >> gotten to yet. But it would eliminate a cast, so that's good (unless these

Re: RFR: 8310906: Fix -Wconversion warnings in runtime, oops and some code header files.

2023-06-27 Thread Stefan Karlsson
On Tue, 27 Jun 2023 12:41:50 GMT, Coleen Phillimore wrote: > This is another version of PR https://github.com/openjdk/jdk/pull/14659 but > I've added a pointer delta function in globalDefinitions.hpp to use for these > pointer diff calculations that return int everywhere. If the name is >

Integrated: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

2023-06-20 Thread Stefan Karlsson
On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson wrote: > Generational ZGC changed the location where the heap object iterator called > the visit function. It used to be called when the objects were popped and > then followed, but it was changed so that the function whe

Re: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

2023-06-20 Thread Stefan Karlsson
On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson wrote: > Generational ZGC changed the location where the heap object iterator called > the visit function. It used to be called when the objects were popped and > then followed, but it was changed so that the function whe

Re: RFR: 8307058: Implementation of Generational ZGC [v6]

2023-05-08 Thread Stefan Karlsson
On Mon, 8 May 2023 10:19:44 GMT, Fei Yang wrote: >> Could you provide the values for `reserved`, `ZAddressHeapBase`, and >> `ZAddressOffsetMax`, when this test is failing. I'd like to know if we can >> make a workaround for you, or if we have to turn off the test for riscv. > > @stefank : I

Integrated: 8307428: jstat tests doesn't tolerate dash in the O column

2023-05-08 Thread Stefan Karlsson
On Thu, 4 May 2023 09:33:49 GMT, Stefan Karlsson wrote: > When running jstat tests like the following: > test/jdk/sun/tools/jstatd/TestJstatdServer.java > > with Generational ZGC we get a failure because the O (old generation > percentage) is reported as `-` and not a number.

Re: RFR: 8307058: Implementation of Generational ZGC [v9]

2023-05-08 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's &g

Re: RFR: 8307058: Implementation of Generational ZGC [v10]

2023-05-09 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's &

Re: RFR: 8307058: Implementation of Generational ZGC [v6]

2023-05-09 Thread Stefan Karlsson
On Tue, 9 May 2023 00:50:56 GMT, Fei Yang wrote: >> That's unfortunate. Could you try this patch, which probes the address range >> to see if it can reserve the memory somewhere else within >> `[ZAddressHeapBase, ZAddressHeapBase+ZAddressOffsetMax)`: >>

Re: RFR: 8307058: Implementation of Generational ZGC [v13]

2023-05-11 Thread Stefan Karlsson
to > mash the two implementations together and sprinkle the GC code with > conditional statements or dynamic dispatches. We have done similar > experiments before. When ZGC was first born, we started an experiment where > we converted G1 into getting the same features as the evolving ZG

Re: RFR: 8307058: Implementation of Generational ZGC [v13]

2023-05-11 Thread Stefan Karlsson
to > mash the two implementations together and sprinkle the GC code with > conditional statements or dynamic dispatches. We have done similar > experiments before. When ZGC was first born, we started an experiment where > we converted G1 into getting the same features as the evolving ZG

Integrated: 8307058: Implementation of Generational ZGC

2023-05-11 Thread Stefan Karlsson
On Wed, 3 May 2023 09:04:50 GMT, Stefan Karlsson wrote: > Hi all, > > Please review the implementation of Generational ZGC, which can be turned on > by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational > ZGC is a major rewrite of the non-generatio

Re: RFR: 8307058: Implementation of Generational ZGC [v13]

2023-05-11 Thread Stefan Karlsson
On Thu, 11 May 2023 12:12:56 GMT, Stefan Karlsson wrote: >> Hi all, >> >> Please review the implementation of Generational ZGC, which can be turned on >> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational >> ZGC is a major rewrite of th

Re: RFR: 8307058: Implementation of Generational ZGC [v2]

2023-05-03 Thread Stefan Karlsson
On Wed, 3 May 2023 12:29:15 GMT, Martin Doerr wrote: > Thanks for fixing PPC64! With this, the VM compiles and the > `test/hotspot/jtreg/gc` tests are passing on linux PPC64le. > > I'm glad to see this PR for JDK 21 LTS. It's a big step forward for ZGC. > Congratulations! Thanks for porting

RFR: 8307058: Implementation of Generational ZGC

2023-05-03 Thread Stefan Karlsson
Hi all, Please review the implementation of Generational ZGC, which can be turned on by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational ZGC is a major rewrite of the non-generational ZGC version that exists in the openjdk/jdk repository. It splits the heap into two

Re: RFR: 8307058: Implementation of Generational ZGC [v2]

2023-05-03 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's &

Re: RFR: 8307058: Implementation of Generational ZGC [v7]

2023-05-04 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC throug

Re: RFR: 8307058: Implementation of Generational ZGC [v6]

2023-05-04 Thread Stefan Karlsson
On Thu, 4 May 2023 20:21:12 GMT, Andrey Turbanov wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> undefine glibc major/minor macros > > test/hotspot/jtreg/runtime/stringtable/Str

Re: RFR: 8307058: Implementation of Generational ZGC [v6]

2023-05-04 Thread Stefan Karlsson
On Fri, 5 May 2023 01:54:48 GMT, Fei Yang wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> undefine glibc major/minor macros > > test/hotspot/gtest/gc/z/test_zForwarding.cpp line

Re: RFR: 8307058: Implementation of Generational ZGC [v6]

2023-05-05 Thread Stefan Karlsson
On Fri, 5 May 2023 06:28:59 GMT, Yadong Wang wrote: >> Thanks for reporting. It would be interesting to see what address you get >> and compare it to the range [ZAddressHeapBase, >> ZAddressHeapBase+ZAddressOffsetMax). > > We emailed to erik to discuss this issue two months ago, and maybe he

Re: RFR: 8307058: Implementation of Generational ZGC [v8]

2023-05-05 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's &g

Re: RFR: 8307058: Implementation of Generational ZGC [v9]

2023-05-08 Thread Stefan Karlsson
There have been many contributors of this patch over the years. I'll do my > best to poke Skara into listing you all, but if you see that I've missed your > name please reach out to me and I'll fix it. > > Testing: we have been continuously running Generational ZGC through Oracle's &g

  1   2   >