From shade at openjdk.org  Tue Jul 11 11:01:33 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Jul 2023 11:01:33 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH
Message-ID: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>

Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161

This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.

Additional testing:
 - [x] Eyeballing instrumented async-profiler initialization path
 - [x] Linux x86_64 fastdebug `serviceability/sa`, default
 - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
 - [ ] Linux x86_64 fastdebug `tier1 tier2`, default
 - [ ] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`

-------------

Commit messages:
 - Potential build failure fixes
 - Better fakery
 - Try to fake the oopDesc properly
 - Remove debug printout
 - Fix

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/51/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=51&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311866
  Stats: 49 lines in 4 files changed: 49 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/51.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/51/head:pull/51

PR: https://git.openjdk.org/lilliput-jdk17u/pull/51

From rkennke at openjdk.org  Tue Jul 11 11:45:35 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 11 Jul 2023 11:45:35 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH
In-Reply-To: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
Message-ID: <A6b-ASR2S2TpSNGDRu5Uqpv_b8oVlYV19uYUUvYMWCs=.f0f2ce13-6a44-4b44-97cf-1817f8c03f03@github.com>

On Tue, 11 Jul 2023 10:51:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161
> 
> This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.
> 
> Additional testing:
>  - [x] Eyeballing instrumented async-profiler initialization path
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, default
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, default
>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`

Ok. It's quite a cludge, but I can't think of a better way, either. Only one question:

src/hotspot/share/oops/oop.hpp line 374:

> 372: };
> 373: 
> 374: // Used by VMStructs when CompactObjectHeaders are enabled.

Is it possible to keep this in vmStructs.*, closer to the override?

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/51#pullrequestreview-1524067504
PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/51#discussion_r1259610743

From shade at openjdk.org  Tue Jul 11 12:19:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Jul 2023 12:19:47 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH [v2]
In-Reply-To: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
Message-ID: <OuH5CE8Vfp8EeSjfxp2Rnw7Rcwa9QCscqymPVLZiTv0=.2774ce20-1054-4b09-ab46-161c89b61bce@github.com>

> Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161
> 
> This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.
> 
> Additional testing:
>  - [x] Eyeballing instrumented async-profiler initialization path
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, default
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, default
>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Move fakeOopDesc

-------------

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/51/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/51/files/051188ae..63fe9746

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=51&range=01
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=51&range=00-01

  Stats: 20 lines in 2 files changed: 10 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/51.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/51/head:pull/51

PR: https://git.openjdk.org/lilliput-jdk17u/pull/51

From shade at openjdk.org  Tue Jul 11 12:19:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Jul 2023 12:19:49 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH [v2]
In-Reply-To: <A6b-ASR2S2TpSNGDRu5Uqpv_b8oVlYV19uYUUvYMWCs=.f0f2ce13-6a44-4b44-97cf-1817f8c03f03@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
 <A6b-ASR2S2TpSNGDRu5Uqpv_b8oVlYV19uYUUvYMWCs=.f0f2ce13-6a44-4b44-97cf-1817f8c03f03@github.com>
Message-ID: <b30zHOLsoynJ89yx0UVK06yVKyKmT-JZU0VLlWQYncI=.75a3dbeb-087d-4df1-a328-b116ce2fe32b@github.com>

On Tue, 11 Jul 2023 11:39:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move fakeOopDesc
>
> src/hotspot/share/oops/oop.hpp line 374:
> 
>> 372: };
>> 373: 
>> 374: // Used by VMStructs when CompactObjectHeaders are enabled.
> 
> Is it possible to keep this in vmStructs.*, closer to the override?

Yes, I think we can. But it has to go in the beginning of the compilation unit, so that it can be used by later macros. Done so in the new commit.

-------------

PR Review Comment: https://git.openjdk.org/lilliput-jdk17u/pull/51#discussion_r1259646449

From rkennke at openjdk.org  Tue Jul 11 12:54:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 11 Jul 2023 12:54:23 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH [v2]
In-Reply-To: <OuH5CE8Vfp8EeSjfxp2Rnw7Rcwa9QCscqymPVLZiTv0=.2774ce20-1054-4b09-ab46-161c89b61bce@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
 <OuH5CE8Vfp8EeSjfxp2Rnw7Rcwa9QCscqymPVLZiTv0=.2774ce20-1054-4b09-ab46-161c89b61bce@github.com>
Message-ID: <IS-WGFLMhMmidEDd5MM-_kEulKSRq2bZ2NEJeMAJNs0=.d34b1e6a-e908-4a49-9d80-0414b6012e85@github.com>

On Tue, 11 Jul 2023 12:19:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161
>> 
>> This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.
>> 
>> Additional testing:
>>  - [x] Eyeballing instrumented async-profiler initialization path
>>  - [x] Linux x86_64 fastdebug `serviceability/sa`, default
>>  - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
>>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, default
>>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move fakeOopDesc

Very nice! Thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/51#pullrequestreview-1524199246

From stuefe at openjdk.org  Tue Jul 11 13:49:21 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 11 Jul 2023 13:49:21 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH [v2]
In-Reply-To: <OuH5CE8Vfp8EeSjfxp2Rnw7Rcwa9QCscqymPVLZiTv0=.2774ce20-1054-4b09-ab46-161c89b61bce@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
 <OuH5CE8Vfp8EeSjfxp2Rnw7Rcwa9QCscqymPVLZiTv0=.2774ce20-1054-4b09-ab46-161c89b61bce@github.com>
Message-ID: <JON4NCajUrSkkV_1Vexad3xYBRVN-r9aQHA0wj2m6Zg=.759c0472-a842-42ab-a4db-52596e086767@github.com>

On Tue, 11 Jul 2023 12:19:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161
>> 
>> This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.
>> 
>> Additional testing:
>>  - [x] Eyeballing instrumented async-profiler initialization path
>>  - [x] Linux x86_64 fastdebug `serviceability/sa`, default
>>  - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
>>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, default
>>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move fakeOopDesc

Regrettable but okay.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/51#pullrequestreview-1524319957

From shade at openjdk.org  Tue Jul 11 14:10:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Jul 2023 14:10:56 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH [v3]
In-Reply-To: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
Message-ID: <968aTt6e5TfGPD1Jd4-v2qLTDhB2h2Cpt6xHP2_TTIQ=.cf07fe67-da57-4280-8a6b-7aefe51e97d2@github.com>

> Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161
> 
> This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.
> 
> Additional testing:
>  - [x] Eyeballing instrumented async-profiler initialization path
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, default
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, default
>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  A bit cleaner override check: do not call on -UCOH

-------------

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/51/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/51/files/63fe9746..28e8f8fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=51&range=02
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=51&range=01-02

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/51.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/51/head:pull/51

PR: https://git.openjdk.org/lilliput-jdk17u/pull/51

From shade at openjdk.org  Tue Jul 11 14:51:48 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 11 Jul 2023 14:51:48 GMT
Subject: [master] RFR: 8311875: [Lilliput] Disallow accessing oop metadata
 vmStructs with +UCOH
Message-ID: <Sawu2B-1PE_MCw2IfNYZCrzwxtpva7N9pOVhgqIyU6I=.1e88cfa7-b379-4f9a-b098-034a5e9c2fea@github.com>

Same as for JDK 17, but for mainline. I had to deal with some upstream reshufflings that moved the agent initialization block.

Additional testing:
 - [x] Eyeballing async-profiler initialization path in default mode and with `+UCOH`
 - [ ] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, default
 - [ ] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, `+UCOH`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/lilliput/pull/101/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput&pr=101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311875
  Stats: 51 lines in 3 files changed: 51 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput/pull/101.diff
  Fetch: git fetch https://git.openjdk.org/lilliput.git pull/101/head:pull/101

PR: https://git.openjdk.org/lilliput/pull/101

From apangin at openjdk.org  Tue Jul 11 16:49:24 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Tue, 11 Jul 2023 16:49:24 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8311866: [Lilliput/JDK17] Disallow
 accessing oop metadata vmStructs with +UCOH [v3]
In-Reply-To: <968aTt6e5TfGPD1Jd4-v2qLTDhB2h2Cpt6xHP2_TTIQ=.cf07fe67-da57-4280-8a6b-7aefe51e97d2@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
 <968aTt6e5TfGPD1Jd4-v2qLTDhB2h2Cpt6xHP2_TTIQ=.cf07fe67-da57-4280-8a6b-7aefe51e97d2@github.com>
Message-ID: <k7j6ADvD3K7OFj4OXubXt6VAp7WY18H-vS1Y2NTDk_E=.b91c2a4b-9c42-47b9-92cb-13d4585114e4@github.com>

On Tue, 11 Jul 2023 14:10:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161
>> 
>> This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.
>> 
>> Additional testing:
>>  - [x] Eyeballing instrumented async-profiler initialization path
>>  - [x] Linux x86_64 fastdebug `serviceability/sa`, default
>>  - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
>>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, default
>>  - [ ] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit cleaner override check: do not call on -UCOH

It was actually an async-profiler bug in a commit that was never released.
I fixed that already.
A tricky workaround in JDK is no more relevant, is it?

-------------

PR Comment: https://git.openjdk.org/lilliput-jdk17u/pull/51#issuecomment-1631156546

From shade at openjdk.org  Wed Jul 12 15:33:31 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 12 Jul 2023 15:33:31 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8311866: [Lilliput/JDK17]
 Disallow accessing oop metadata vmStructs with +UCOH
In-Reply-To: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
References: <1ZCG0ixvT3ShRhV-i4d3qLjgb18RFCr4BDR1lw8p7lA=.3f8f863c-155a-443e-af7a-fcff08e9e4cb@github.com>
Message-ID: <ifjR_qRyH_xNb8QT2jwDIjtA7Bt16zlfAHgOJiwISRM=.46258ea2-376b-4cdc-ad9b-091a98c85007@github.com>

On Tue, 11 Jul 2023 10:51:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Allowing external tools to access e.g. `oopDesc::_metadata._klass` with `+UCOH` is error-prone. We have seen async-profiler poking into this field to resolve classes: https://github.com/async-profiler/async-profiler/blob/117594bb4d1ce61b073c8a9cea438b33f3f09c81/src/vmStructs.cpp#L158-L161
> 
> This hides the fields from vmStructs with +UCOH. This is the least intrusive way of achieving this I can come up with.
> 
> Additional testing:
>  - [x] Eyeballing instrumented async-profiler initialization path
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, default
>  - [x] Linux x86_64 fastdebug `serviceability/sa`, `+UCOH`
>  - [x] Linux x86_64 fastdebug `tier1 tier2`, default
>  - [x] Linux x86_64 fastdebug `tier1 tier2`, `+UCOH`

This pull request has now been integrated.

Changeset: c4cda3ce
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/c4cda3ce9011a6e647a5b5bbe7cefef521c95c59
Stats:     51 lines in 3 files changed: 51 ins; 0 del; 0 mod

8311866: [Lilliput/JDK17] Disallow accessing oop metadata vmStructs with +UCOH

Reviewed-by: rkennke, stuefe

-------------

PR: https://git.openjdk.org/lilliput-jdk17u/pull/51

From rkennke at openjdk.org  Fri Jul 14 12:16:56 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 14 Jul 2023 12:16:56 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312095: [Lilliput/JDK17] Reinstate
 use of BiasedLockingCounters
Message-ID: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>

In x86_64.ad we accidentally dropped _counters to NULL in a fast_lock() call. This means we're not counting BiasedLocking calls correctly. Let's fix that. It is only relevant in 17 because biased locking has been removed in later release.

Testing:
 - [ ] tier1 +UseBiasedLocking

-------------

Commit messages:
 - 8312095: [Lilliput/JDK17] Reinstate use of BiasedLockingCounters

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/52/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=52&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312095
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/52.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/52/head:pull/52

PR: https://git.openjdk.org/lilliput-jdk17u/pull/52

From shade at openjdk.org  Fri Jul 14 14:01:24 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 14 Jul 2023 14:01:24 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312095: [Lilliput/JDK17]
 Reinstate use of BiasedLockingCounters
In-Reply-To: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>
References: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>
Message-ID: <WQDMIGOVKuGKwr9Y6VhDNkfGu74qJzvEGPYcq0446KQ=.16edce25-627a-4837-bf44-8f6232817a83@github.com>

On Fri, 14 Jul 2023 12:08:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In x86_64.ad we accidentally dropped _counters to NULL in a fast_lock() call. This means we're not counting BiasedLocking calls correctly. Let's fix that. It is only relevant in 17 because biased locking has been removed in later release.
> 
> Testing:
>  - [ ] tier1 +UseBiasedLocking

`x86_32.ad` as well?

-------------

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/52#pullrequestreview-1530361747

From rkennke at openjdk.org  Fri Jul 14 14:18:45 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 14 Jul 2023 14:18:45 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312095: [Lilliput/JDK17]
 Reinstate use of BiasedLockingCounters [v2]
In-Reply-To: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>
References: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>
Message-ID: <GhEO28_vVQWmZ6he6rIZkXRRo1mK4sg4NFXIowJJzYA=.49d4cc23-a7d5-4eac-98c2-c7314e516a72@github.com>

> In x86_64.ad we accidentally dropped _counters to NULL in a fast_lock() call. This means we're not counting BiasedLocking calls correctly. Let's fix that. It is only relevant in 17 because biased locking has been removed in later release.
> 
> Testing:
>  - [ ] tier1 +UseBiasedLocking

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  x86_32.ad fix

-------------

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/52/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/52/files/8c94c90b..27f63a24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=52&range=01
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=52&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/52.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/52/head:pull/52

PR: https://git.openjdk.org/lilliput-jdk17u/pull/52

From shade at openjdk.org  Fri Jul 14 14:18:46 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 14 Jul 2023 14:18:46 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312095: [Lilliput/JDK17]
 Reinstate use of BiasedLockingCounters [v2]
In-Reply-To: <GhEO28_vVQWmZ6he6rIZkXRRo1mK4sg4NFXIowJJzYA=.49d4cc23-a7d5-4eac-98c2-c7314e516a72@github.com>
References: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>
 <GhEO28_vVQWmZ6he6rIZkXRRo1mK4sg4NFXIowJJzYA=.49d4cc23-a7d5-4eac-98c2-c7314e516a72@github.com>
Message-ID: <e091BcZILuYp-uGA7Mv0D2KXE6lqQalE3BHULCry6EQ=.b91326b7-17ec-47f7-b4a6-59ba628a2016@github.com>

On Fri, 14 Jul 2023 14:13:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In x86_64.ad we accidentally dropped _counters to NULL in a fast_lock() call. This means we're not counting BiasedLocking calls correctly. Let's fix that. It is only relevant in 17 because biased locking has been removed in later release.
>> 
>> Testing:
>>  - [ ] tier1 +UseBiasedLocking
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   x86_32.ad fix

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/52#pullrequestreview-1530386879

From rkennke at openjdk.org  Fri Jul 14 17:04:31 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 14 Jul 2023 17:04:31 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8312095: [Lilliput/JDK17]
 Reinstate use of BiasedLockingCounters
In-Reply-To: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>
References: <rCH5aJuvDcDzvhsaPD5_qpPEUEJVQz6doCunUhSspy0=.cc6446ae-dfac-4ad3-a7e1-79a147fd977d@github.com>
Message-ID: <VinNPNXWWzpuwFCJXb_ng1kIZoLy7IPOjM_hdE1npUI=.405cd687-7d0e-4ba9-85be-1d9c98d44ae7@github.com>

On Fri, 14 Jul 2023 12:08:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In x86_64.ad we accidentally dropped _counters to NULL in a fast_lock() call. This means we're not counting BiasedLocking calls correctly. Let's fix that. It is only relevant in 17 because biased locking has been removed in later release.
> 
> Testing:
>  - [x] tier1 +UseBiasedLocking

This pull request has now been integrated.

Changeset: 1e625bee
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/1e625bee590c3f8e87138fcaa99df6527bcb6428
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8312095: [Lilliput/JDK17] Reinstate use of BiasedLockingCounters

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/lilliput-jdk17u/pull/52

From rkennke at openjdk.org  Mon Jul 17 10:51:28 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 17 Jul 2023 10:51:28 GMT
Subject: [master] Withdrawn: 8304341: [Lilliput] Use fixed-size lock-stack
In-Reply-To: <HdS6GQ1Ulsh9EDFCR_r-1i619FdE4Q-VEy9mFwMs5LE=.39289003-ced6-4578-b842-02c77088eda3@github.com>
References: <HdS6GQ1Ulsh9EDFCR_r-1i619FdE4Q-VEy9mFwMs5LE=.39289003-ced6-4578-b842-02c77088eda3@github.com>
Message-ID: <kow7c40-kFmABZc-hsHTRGlHDt6avtupaplU45ppyXw=.84fc61eb-a95b-48b3-9665-5c55a6e570ad@github.com>

On Thu, 16 Mar 2023 12:12:30 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Until now, we used to have a variable-sized lock-stack: when pushing an object to it and capacity is exceeded, it would re-allocate a new stack and use that. However, experiments show that the lock-stack very rarely exceeds 5 slots (I have not yet found a workload that does actually exceed it). It makes sense to make the lock-stack a fixed-size array: it makes addressing the lock-stack simpler and more efficient and it increases the likelyhood of the lock-stack being in CPU cache. If the lock-stack is ever exceeded, we would not do stack-locking at all, but instead inflate the monitor and use that.
> 
> This is already integrated in the related upstream PR: https://github.com/openjdk/jdk/pull/10907
> 
> Testing:
>  - [x] tier1
>  - [ ] tier2

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/lilliput/pull/81

From rkennke at openjdk.org  Mon Jul 17 11:05:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 17 Jul 2023 11:05:27 GMT
Subject: [master] Integrated: 8310010: [Lilliput] SA: Fix oop array element
 alignment
In-Reply-To: <XKiK0dw0jDptDUfNuGsF7Hi1lEOOiLWg9qIAWUmIj4c=.0ca2ba16-87e9-4140-aab4-dee802361abf@github.com>
References: <XKiK0dw0jDptDUfNuGsF7Hi1lEOOiLWg9qIAWUmIj4c=.0ca2ba16-87e9-4140-aab4-dee802361abf@github.com>
Message-ID: <VbrQRRkDwHIoU8XxzipcDTohr5GD2vcwFVl2ZytPYko=.191df596-06dc-486f-aa88-80063fa5615f@github.com>

On Wed, 14 Jun 2023 10:12:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> When running with -COOPS, oop array elements need to be 8-byte-aligned. We have this correct in runtime, but not in the SA. Notably, the problem manifests with ZGC.
> The problem is already fixed in #11044.
> 
> Testing:
>  - [x] serviceability/sa -XX:-UseCompressedOops

This pull request has now been integrated.

Changeset: a8b7c010
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/a8b7c010f47e3c7303e9ceffa76f1983f4c6523f
Stats:     21 lines in 2 files changed: 12 ins; 7 del; 2 mod

8310010: [Lilliput] SA: Fix oop array element alignment

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/lilliput/pull/96

From rkennke at openjdk.org  Mon Jul 17 11:14:34 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 17 Jul 2023 11:14:34 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312171: [Lilliput/JDK17] Fix oop
 array element alignment
Message-ID: <bpcCaz4dsJ23KYtLZ6GgWOrBcbhuwPQE-CtHns9yIqM=.309f8766-b2cd-499f-99b1-b353ebebb12d@github.com>

When running with -COOPS, oop array elements need to be 8-byte-aligned. We have this correct in runtime, but not in the SA. Notably, the problem manifests with ZGC.

This is a straight backport of https://github.com/openjdk/lilliput/pull/96.

The problem is already fixed in https://github.com/openjdk/jdk/pull/11044.

-------------

Commit messages:
 - 8312171: [Lilliput/JDK17] Fix oop array element alignment

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/53/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=53&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312171
  Stats: 21 lines in 2 files changed: 12 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/53.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/53/head:pull/53

PR: https://git.openjdk.org/lilliput-jdk17u/pull/53

From shade at openjdk.org  Mon Jul 17 11:27:24 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 17 Jul 2023 11:27:24 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312171: [Lilliput/JDK17] Fix oop
 array element alignment
In-Reply-To: <bpcCaz4dsJ23KYtLZ6GgWOrBcbhuwPQE-CtHns9yIqM=.309f8766-b2cd-499f-99b1-b353ebebb12d@github.com>
References: <bpcCaz4dsJ23KYtLZ6GgWOrBcbhuwPQE-CtHns9yIqM=.309f8766-b2cd-499f-99b1-b353ebebb12d@github.com>
Message-ID: <nrzrKx_ikeyM8gZQbDTC4vX0E5SO09bkCEbHAX15wtU=.4522d2e1-8c55-46d7-a296-7cb15a57144e@github.com>

On Mon, 17 Jul 2023 11:07:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> When running with -COOPS, oop array elements need to be 8-byte-aligned. We have this correct in runtime, but not in the SA. Notably, the problem manifests with ZGC.
> 
> This is a straight backport of https://github.com/openjdk/lilliput/pull/96.
> 
> The problem is already fixed in https://github.com/openjdk/jdk/pull/11044.

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/53#pullrequestreview-1532537108

From rkennke at openjdk.org  Mon Jul 17 14:11:31 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 17 Jul 2023 14:11:31 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8312171: [Lilliput/JDK17] Fix
 oop array element alignment
In-Reply-To: <bpcCaz4dsJ23KYtLZ6GgWOrBcbhuwPQE-CtHns9yIqM=.309f8766-b2cd-499f-99b1-b353ebebb12d@github.com>
References: <bpcCaz4dsJ23KYtLZ6GgWOrBcbhuwPQE-CtHns9yIqM=.309f8766-b2cd-499f-99b1-b353ebebb12d@github.com>
Message-ID: <pfKrYlyft1mY9TFShsePC3dy0xWScsNLq4CdK9RWddc=.c519ed7f-8768-4251-86b3-a48f895adc8d@github.com>

On Mon, 17 Jul 2023 11:07:50 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> When running with -COOPS, oop array elements need to be 8-byte-aligned. We have this correct in runtime, but not in the SA. Notably, the problem manifests with ZGC.
> 
> This is a straight backport of https://github.com/openjdk/lilliput/pull/96.
> 
> The problem is already fixed in https://github.com/openjdk/jdk/pull/11044.

This pull request has now been integrated.

Changeset: 3d224e33
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/3d224e33db8495de7b32b537fd544eaa7eaf4c33
Stats:     21 lines in 2 files changed: 12 ins; 7 del; 2 mod

8312171: [Lilliput/JDK17] Fix oop array element alignment

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/lilliput-jdk17u/pull/53

From rkennke at openjdk.org  Wed Jul 19 11:18:13 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 19 Jul 2023 11:18:13 GMT
Subject: [master] RFR: 8311875: [Lilliput] Disallow accessing oop metadata
 vmStructs with +UCOH
In-Reply-To: <Sawu2B-1PE_MCw2IfNYZCrzwxtpva7N9pOVhgqIyU6I=.1e88cfa7-b379-4f9a-b098-034a5e9c2fea@github.com>
References: <Sawu2B-1PE_MCw2IfNYZCrzwxtpva7N9pOVhgqIyU6I=.1e88cfa7-b379-4f9a-b098-034a5e9c2fea@github.com>
Message-ID: <Mt9JHTSpFsXawm_TQqafpQyyuwa7fCVuSvwx6CpaPWA=.8ec9fc32-99b4-4a74-8c1e-e4c780826dd4@github.com>

On Tue, 11 Jul 2023 14:45:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as for JDK 17, but for mainline. I had to deal with some upstream reshufflings that moved the agent initialization block.
> 
> Additional testing:
>  - [x] Eyeballing async-profiler initialization path in default mode and with `+UCOH`
>  - [x] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, default
>  - [x] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, `+UCOH`

Looks good, thank you!

-------------

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/lilliput/pull/101#pullrequestreview-1536863459

From shade at openjdk.org  Wed Jul 19 11:22:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Jul 2023 11:22:12 GMT
Subject: [master] RFR: 8311875: [Lilliput] Disallow accessing oop metadata
 vmStructs with +UCOH
In-Reply-To: <Sawu2B-1PE_MCw2IfNYZCrzwxtpva7N9pOVhgqIyU6I=.1e88cfa7-b379-4f9a-b098-034a5e9c2fea@github.com>
References: <Sawu2B-1PE_MCw2IfNYZCrzwxtpva7N9pOVhgqIyU6I=.1e88cfa7-b379-4f9a-b098-034a5e9c2fea@github.com>
Message-ID: <HbuE1gHRqXI-9p1kzW1OYjZyjw0_vs8TIwhrB6lM7lU=.171f2907-b5c3-465f-8420-2da3a596f896@github.com>

On Tue, 11 Jul 2023 14:45:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as for JDK 17, but for mainline. I had to deal with some upstream reshufflings that moved the agent initialization block.
> 
> Additional testing:
>  - [x] Eyeballing async-profiler initialization path in default mode and with `+UCOH`
>  - [x] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, default
>  - [x] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, `+UCOH`

Thanks!

-------------

PR Comment: https://git.openjdk.org/lilliput/pull/101#issuecomment-1641896204

From shade at openjdk.org  Wed Jul 19 11:22:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Jul 2023 11:22:12 GMT
Subject: [master] Integrated: 8311875: [Lilliput] Disallow accessing oop
 metadata vmStructs with +UCOH
In-Reply-To: <Sawu2B-1PE_MCw2IfNYZCrzwxtpva7N9pOVhgqIyU6I=.1e88cfa7-b379-4f9a-b098-034a5e9c2fea@github.com>
References: <Sawu2B-1PE_MCw2IfNYZCrzwxtpva7N9pOVhgqIyU6I=.1e88cfa7-b379-4f9a-b098-034a5e9c2fea@github.com>
Message-ID: <DWQqaoHsR743n5LUPGnxpAcTbNT-R4ldgQtgGjI3daY=.298862b6-20f5-434c-a6eb-35f69c9f9640@github.com>

On Tue, 11 Jul 2023 14:45:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Same as for JDK 17, but for mainline. I had to deal with some upstream reshufflings that moved the agent initialization block.
> 
> Additional testing:
>  - [x] Eyeballing async-profiler initialization path in default mode and with `+UCOH`
>  - [x] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, default
>  - [x] Linux x86_65 fastdebug `serviceability/sa tier1 tier2`, `+UCOH`

This pull request has now been integrated.

Changeset: 2726f595
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/lilliput/commit/2726f59519dce5336a66fbe1129666073555d945
Stats:     51 lines in 3 files changed: 51 ins; 0 del; 0 mod

8311875: [Lilliput] Disallow accessing oop metadata vmStructs with +UCOH

Reviewed-by: rkennke

-------------

PR: https://git.openjdk.org/lilliput/pull/101

From rkennke at openjdk.org  Mon Jul 24 13:41:33 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 24 Jul 2023 13:41:33 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308296: [Lilliput/JDK17]
 Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput [v3]
In-Reply-To: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>
References: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>
Message-ID: <t2uYRTdBxgwhQeD1dWN1pEEEr-IRCgxknAgvIvcX-ao=.037c9338-b2af-45f3-9e89-81512c8c7a96@github.com>

> We should cherry-pick [JDK-8275415](https://bugs.openjdk.org/browse/JDK-8275415) into Lilliput/JDK17, otherwise running leak-profiler with Lilliput would crash. The change has been backported to jdk17u already, let's integrate it separately before merging so that we have a change to apply on downstreams.
> 
> The original change applies cleanly on top of lilliput/jdk17u.
> 
> Testing:
>  - [x] tier1
>  - [x] jdk/jfr

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Re-enable JFR leak-profiler with Lilliput, and remove ProblemList entries
 - Merge remote-tracking branch 'upstream/lilliput' into JDK-8308296
 - Merge branch 'lilliput' into JDK-8308296
 - 8308296: [Lilliput/JDK17] Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput

-------------

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/20/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/20/files/9bb30dc3..64aaa425

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=20&range=02
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=20&range=01-02

  Stats: 2202 lines in 115 files changed: 1409 ins; 353 del; 440 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/20/head:pull/20

PR: https://git.openjdk.org/lilliput-jdk17u/pull/20

From rkennke at openjdk.org  Mon Jul 24 13:54:27 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 24 Jul 2023 13:54:27 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312606: [Lilliput/JDK17] Cherry-pick:
 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed
 "assert(!contains(edge->reference())) failed: invariant"
Message-ID: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>

After [JDK-8308296](https://bugs.openjdk.org/browse/JDK-8308296) we should also cherry-pick the follow-up fix [JDK-8276333](https://bugs.openjdk.org/browse/JDK-8276333) to avoid a mess when merging from upstream jdk17u.

-------------

Commit messages:
 - 8312606: [Lilliput/JDK17] Cherry-pick: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed "assert(>reference())) failed: invariant"
 - Re-enable JFR leak-profiler with Lilliput, and remove ProblemList entries
 - Merge remote-tracking branch 'upstream/lilliput' into JDK-8308296
 - Merge branch 'lilliput' into JDK-8308296
 - 8308296: [Lilliput/JDK17] Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput

Changes: https://git.openjdk.org/lilliput-jdk17u/pull/54/files
 Webrev: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=54&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312606
  Stats: 176 lines in 7 files changed: 94 ins; 74 del; 8 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/54.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/54/head:pull/54

PR: https://git.openjdk.org/lilliput-jdk17u/pull/54

From rkennke at openjdk.org  Wed Jul 26 15:38:16 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 26 Jul 2023 15:38:16 GMT
Subject: [lilliput-jdk17u:pr/20] RFR: 8312606: [Lilliput/JDK17]
 Cherry-pick: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed
 "assert(!contains(edge->reference())) failed: invariant" [v2]
In-Reply-To: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>
References: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>
Message-ID: <-K_dqu8mT5jyIwwOVVAtJStMWuhIO30xwLjA4r3iAA8=.5ea2d45c-65fa-411a-8a93-2f5274fa60aa@github.com>

> After [JDK-8308296](https://bugs.openjdk.org/browse/JDK-8308296) we should also cherry-pick the follow-up fix [JDK-8276333](https://bugs.openjdk.org/browse/JDK-8276333) to avoid a mess when merging from upstream jdk17u.

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/54/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/54/files/365d50e0..365d50e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=54&range=01
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=54&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/54.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/54/head:pull/54

PR: https://git.openjdk.org/lilliput-jdk17u/pull/54

From shade at openjdk.org  Wed Jul 26 16:57:06 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Jul 2023 16:57:06 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8308296: [Lilliput/JDK17]
 Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput [v3]
In-Reply-To: <t2uYRTdBxgwhQeD1dWN1pEEEr-IRCgxknAgvIvcX-ao=.037c9338-b2af-45f3-9e89-81512c8c7a96@github.com>
References: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>
 <t2uYRTdBxgwhQeD1dWN1pEEEr-IRCgxknAgvIvcX-ao=.037c9338-b2af-45f3-9e89-81512c8c7a96@github.com>
Message-ID: <iz4C0AbsIQRzgaAjDcgq3yKFkkMo4R1WGRx9yzfUCNA=.a7755217-fdf7-44f7-8a8c-0304d45a5465@github.com>

On Mon, 24 Jul 2023 13:41:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We should cherry-pick [JDK-8275415](https://bugs.openjdk.org/browse/JDK-8275415) into Lilliput/JDK17, otherwise running leak-profiler with Lilliput would crash. The change has been backported to jdk17u already, let's integrate it separately before merging so that we have a change to apply on downstreams.
>> 
>> The original change applies cleanly on top of lilliput/jdk17u.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] jdk/jfr
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Re-enable JFR leak-profiler with Lilliput, and remove ProblemList entries
>  - Merge remote-tracking branch 'upstream/lilliput' into JDK-8308296
>  - Merge branch 'lilliput' into JDK-8308296
>  - 8308296: [Lilliput/JDK17] Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput

Looks good!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/20#pullrequestreview-1548201057

From shade at openjdk.org  Wed Jul 26 16:59:04 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 26 Jul 2023 16:59:04 GMT
Subject: [lilliput-jdk17u:pr/20] RFR: 8312606: [Lilliput/JDK17]
 Cherry-pick: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed
 "assert(!contains(edge->reference())) failed: invariant" [v2]
In-Reply-To: <-K_dqu8mT5jyIwwOVVAtJStMWuhIO30xwLjA4r3iAA8=.5ea2d45c-65fa-411a-8a93-2f5274fa60aa@github.com>
References: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>
 <-K_dqu8mT5jyIwwOVVAtJStMWuhIO30xwLjA4r3iAA8=.5ea2d45c-65fa-411a-8a93-2f5274fa60aa@github.com>
Message-ID: <s-qX19VwppQvesL4yqa1oS6I6OmRK5sAivrxpdhi--s=.86b906b6-2b75-4762-9b9c-1503c4d76b48@github.com>

On Wed, 26 Jul 2023 15:38:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> After [JDK-8308296](https://bugs.openjdk.org/browse/JDK-8308296) we should also cherry-pick the follow-up fix [JDK-8276333](https://bugs.openjdk.org/browse/JDK-8276333) to avoid a mess when merging from upstream jdk17u.
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Looks good.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/lilliput-jdk17u/pull/54#pullrequestreview-1548202860

From rkennke at openjdk.org  Wed Jul 26 17:39:07 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 26 Jul 2023 17:39:07 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8308296: [Lilliput/JDK17]
 Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput
In-Reply-To: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>
References: <rsnJgEw0SqG-TFJQSozpqJ20q34mxQL_IaL6juCetVQ=.e18522b7-1c91-43cc-abc0-adbc7399129e@github.com>
Message-ID: <O7q_cAgLsZgeEM8k_yLcnycB24Ax-ohuG6l1gl441YU=.78207107-fb4f-46f0-a27b-90d9929f4d5c@github.com>

On Wed, 17 May 2023 16:21:49 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We should cherry-pick [JDK-8275415](https://bugs.openjdk.org/browse/JDK-8275415) into Lilliput/JDK17, otherwise running leak-profiler with Lilliput would crash. The change has been backported to jdk17u already, let's integrate it separately before merging so that we have a change to apply on downstreams.
> 
> The original change applies cleanly on top of lilliput/jdk17u.
> 
> Testing:
>  - [x] tier1
>  - [x] jdk/jfr

This pull request has now been integrated.

Changeset: eb8da489
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/eb8da489d595ff1b39ab6087c14d068e86efc03c
Stats:     147 lines in 6 files changed: 75 ins; 65 del; 7 mod

8308296: [Lilliput/JDK17] Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/lilliput-jdk17u/pull/20

From rkennke at openjdk.org  Wed Jul 26 18:20:06 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 26 Jul 2023 18:20:06 GMT
Subject: [lilliput-jdk17u:lilliput] RFR: 8312606: [Lilliput/JDK17]
 Cherry-pick: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed
 "assert(!contains(edge->reference())) failed: invariant" [v3]
In-Reply-To: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>
References: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>
Message-ID: <SnvuYTQBRO0uCDUiPsr0J7jsyubSsk0iStjhZc-Sa9g=.65fb30da-3678-4471-b9b2-7227cfa805d0@github.com>

> After [JDK-8308296](https://bugs.openjdk.org/browse/JDK-8308296) we should also cherry-pick the follow-up fix [JDK-8276333](https://bugs.openjdk.org/browse/JDK-8276333) to avoid a mess when merging from upstream jdk17u.

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/lilliput' into JDK-8312606
 - 8312606: [Lilliput/JDK17] Cherry-pick: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed "assert(>reference())) failed: invariant"
 - Re-enable JFR leak-profiler with Lilliput, and remove ProblemList entries
 - Merge remote-tracking branch 'upstream/lilliput' into JDK-8308296
 - Merge branch 'lilliput' into JDK-8308296
 - 8308296: [Lilliput/JDK17] Cherry-pick: 8275415: Prepare Leak Profiler for Lilliput

-------------

Changes:
  - all: https://git.openjdk.org/lilliput-jdk17u/pull/54/files
  - new: https://git.openjdk.org/lilliput-jdk17u/pull/54/files/365d50e0..2b9f9f1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=54&range=02
 - incr: https://webrevs.openjdk.org/?repo=lilliput-jdk17u&pr=54&range=01-02

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/lilliput-jdk17u/pull/54.diff
  Fetch: git fetch https://git.openjdk.org/lilliput-jdk17u.git pull/54/head:pull/54

PR: https://git.openjdk.org/lilliput-jdk17u/pull/54

From rkennke at openjdk.org  Wed Jul 26 18:20:06 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 26 Jul 2023 18:20:06 GMT
Subject: [lilliput-jdk17u:lilliput] Integrated: 8312606: [Lilliput/JDK17]
 Cherry-pick: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed
 "assert(!contains(edge->reference())) failed: invariant"
In-Reply-To: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>
References: <VynKHvOGjLyLSrKy_RUiDFflIrUPA7cj-8YVzSzBo2U=.f3e01d92-e6b8-4f5e-bd03-f768d750d38f@github.com>
Message-ID: <nwGr924dTDsZRtu0cmW7NdWDE9xId-AWVSusbTsJaHE=.1da57a69-a26e-466f-9437-01a7e4e16c5c@github.com>

On Mon, 24 Jul 2023 13:47:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> After [JDK-8308296](https://bugs.openjdk.org/browse/JDK-8308296) we should also cherry-pick the follow-up fix [JDK-8276333](https://bugs.openjdk.org/browse/JDK-8276333) to avoid a mess when merging from upstream jdk17u.

This pull request has now been integrated.

Changeset: 73660798
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/lilliput-jdk17u/commit/736607989f63b5ef6e5d98debbe2e1f62983c771
Stats:     31 lines in 2 files changed: 19 ins; 9 del; 3 mod

8312606: [Lilliput/JDK17] Cherry-pick: 8276333: jdk/jfr/event/oldobject/TestLargeRootSet.java failed "assert(!contains(edge->reference())) failed: invariant"

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/lilliput-jdk17u/pull/54