Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v4]
On Thu, 17 Feb 2022 23:20:41 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use InstanceKlass::do_local_static_fields for some field iterations > > Looks good. Minor comment below. > Also, several files with copyright year 2021 need updating. Thanks @calvinccheung and @coleenp for the review. Passed tiers 1-5. - PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v7]
> **Background:**
>
> In the Java Language, Enums can be tested for equality, so the constants in
> an Enum type must be unique. Javac compiles an enum declaration like this:
>
>
> public enum Day { SUNDAY, MONDAY ... }
>
>
> to
>
>
> public class Day extends java.lang.Enum {
> public static final SUNDAY = new Day("SUNDAY");
> public static final MONDAY = new Day("MONDAY"); ...
> }
>
>
> With CDS archived heap objects, `Day::` is executed twice: once
> during `java -Xshare:dump`, and once during normal JVM execution. If the
> archived heap objects references one of the Enum constants created at dump
> time, we will violate the uniqueness requirements of the Enum constants at
> runtime. See the test case in the description of
> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>
> **Fix:**
>
> During -Xshare:dump, if we discovered that an Enum constant of type X is
> archived, we archive all constants of type X. At Runtime, type X will skip
> the normal execution of `X::`. Instead, we run
> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that
> were saved at dump time.
>
> This is safe as we know that `X::` has no observable side effect --
> it only creates the constants of type X, as well as the synthetic value
> `X::$VALUES`, which cannot be observed until X is fully initialized.
>
> **Verification:**
>
> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
> similar problems where the archived heap objects reference a static field
> that may be recreated at runtime. There are some manual steps involved, but I
> analyzed the potential problems found by the tool are they are all safe
> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
> An example trace of this tool can be found at
> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>
> **Testing:**
>
> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
Ioi Lam has updated the pull request with a new target base due to a merge or a
rebase. The pull request now contains 10 commits:
- fixed copyright year
- Merge branch 'master' into 8275731-heapshared-enum
- fixed whitespace
- Fixed comments per @calvinccheung review
- Merge branch 'master' into 8275731-heapshared-enum
- Use InstanceKlass::do_local_static_fields for some field iterations
- Merge branch 'master' into 8275731-heapshared-enum
- added exclusions needed by "java -Xshare:dump -ea -esa"
- Comments from @calvinccheung off-line
- 8275731: CDS archived enums objects are recreated at runtime
-
Changes: https://git.openjdk.java.net/jdk/pull/6653/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6653=06
Stats: 860 lines in 16 files changed: 807 ins; 4 del; 49 mod
Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]
On Wed, 19 Jan 2022 05:44:10 GMT, Ioi Lam wrote:
>> src/hotspot/share/cds/heapShared.cpp line 433:
>>
>>> 431: oop mirror = k->java_mirror();
>>> 432: int i = 0;
>>> 433: for (JavaFieldStream fs(k); !fs.done(); fs.next()) {
>>
>> This seems like it should also use InstanceKlass::do_local_static_fields.
>
> Converting this to InstanceKlass::do_nonstatic_fields() is difficult because
> the loop body references 7 different variables declared outside of the loop.
>
> One thing I tried is to add a new version of do_nonstatic_fields2() that
> supports C++ lambdas. You can see my experiment from here:
>
> https://github.com/openjdk/jdk/compare/master...iklam:lambda-for-instanceklass-do_local_static_fields2?expand=1
>
> I changed all my new code to use the do_nonstatic_fields2() function with
> lambda.
Ok, if it requires lambdas and additional change, never mind then.
-
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v6]
On Wed, 23 Feb 2022 04:15:28 GMT, Ioi Lam wrote:
>> **Background:**
>>
>> In the Java Language, Enums can be tested for equality, so the constants in
>> an Enum type must be unique. Javac compiles an enum declaration like this:
>>
>>
>> public enum Day { SUNDAY, MONDAY ... }
>>
>>
>> to
>>
>>
>> public class Day extends java.lang.Enum {
>> public static final SUNDAY = new Day("SUNDAY");
>> public static final MONDAY = new Day("MONDAY"); ...
>> }
>>
>>
>> With CDS archived heap objects, `Day::` is executed twice: once
>> during `java -Xshare:dump`, and once during normal JVM execution. If the
>> archived heap objects references one of the Enum constants created at dump
>> time, we will violate the uniqueness requirements of the Enum constants at
>> runtime. See the test case in the description of
>> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>>
>> **Fix:**
>>
>> During -Xshare:dump, if we discovered that an Enum constant of type X is
>> archived, we archive all constants of type X. At Runtime, type X will skip
>> the normal execution of `X::`. Instead, we run
>> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X
>> that were saved at dump time.
>>
>> This is safe as we know that `X::` has no observable side effect --
>> it only creates the constants of type X, as well as the synthetic value
>> `X::$VALUES`, which cannot be observed until X is fully initialized.
>>
>> **Verification:**
>>
>> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
>> similar problems where the archived heap objects reference a static field
>> that may be recreated at runtime. There are some manual steps involved, but
>> I analyzed the potential problems found by the tool are they are all safe
>> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
>> An example trace of this tool can be found at
>> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>>
>> **Testing:**
>>
>> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
>
> Ioi Lam has updated the pull request incrementally with one additional commit
> since the last revision:
>
> fixed whitespace
Sorry for the long delay. It's a big change, but a lot in debug so that's ok.
Looks good.
-
Marked as reviewed by coleenp (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v6]
> **Background:**
>
> In the Java Language, Enums can be tested for equality, so the constants in
> an Enum type must be unique. Javac compiles an enum declaration like this:
>
>
> public enum Day { SUNDAY, MONDAY ... }
>
>
> to
>
>
> public class Day extends java.lang.Enum {
> public static final SUNDAY = new Day("SUNDAY");
> public static final MONDAY = new Day("MONDAY"); ...
> }
>
>
> With CDS archived heap objects, `Day::` is executed twice: once
> during `java -Xshare:dump`, and once during normal JVM execution. If the
> archived heap objects references one of the Enum constants created at dump
> time, we will violate the uniqueness requirements of the Enum constants at
> runtime. See the test case in the description of
> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>
> **Fix:**
>
> During -Xshare:dump, if we discovered that an Enum constant of type X is
> archived, we archive all constants of type X. At Runtime, type X will skip
> the normal execution of `X::`. Instead, we run
> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that
> were saved at dump time.
>
> This is safe as we know that `X::` has no observable side effect --
> it only creates the constants of type X, as well as the synthetic value
> `X::$VALUES`, which cannot be observed until X is fully initialized.
>
> **Verification:**
>
> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
> similar problems where the archived heap objects reference a static field
> that may be recreated at runtime. There are some manual steps involved, but I
> analyzed the potential problems found by the tool are they are all safe
> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
> An example trace of this tool can be found at
> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>
> **Testing:**
>
> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
Ioi Lam has updated the pull request incrementally with one additional commit
since the last revision:
fixed whitespace
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6653/files
- new: https://git.openjdk.java.net/jdk/pull/6653/files/4764075e..c6e9be1d
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=6653=05
- incr: https://webrevs.openjdk.java.net/?repo=jdk=6653=04-05
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v5]
> **Background:**
>
> In the Java Language, Enums can be tested for equality, so the constants in
> an Enum type must be unique. Javac compiles an enum declaration like this:
>
>
> public enum Day { SUNDAY, MONDAY ... }
>
>
> to
>
>
> public class Day extends java.lang.Enum {
> public static final SUNDAY = new Day("SUNDAY");
> public static final MONDAY = new Day("MONDAY"); ...
> }
>
>
> With CDS archived heap objects, `Day::` is executed twice: once
> during `java -Xshare:dump`, and once during normal JVM execution. If the
> archived heap objects references one of the Enum constants created at dump
> time, we will violate the uniqueness requirements of the Enum constants at
> runtime. See the test case in the description of
> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>
> **Fix:**
>
> During -Xshare:dump, if we discovered that an Enum constant of type X is
> archived, we archive all constants of type X. At Runtime, type X will skip
> the normal execution of `X::`. Instead, we run
> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that
> were saved at dump time.
>
> This is safe as we know that `X::` has no observable side effect --
> it only creates the constants of type X, as well as the synthetic value
> `X::$VALUES`, which cannot be observed until X is fully initialized.
>
> **Verification:**
>
> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
> similar problems where the archived heap objects reference a static field
> that may be recreated at runtime. There are some manual steps involved, but I
> analyzed the potential problems found by the tool are they are all safe
> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
> An example trace of this tool can be found at
> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>
> **Testing:**
>
> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
Ioi Lam has updated the pull request with a new target base due to a merge or a
rebase. The pull request now contains seven commits:
- Fixed comments per @calvinccheung review
- Merge branch 'master' into 8275731-heapshared-enum
- Use InstanceKlass::do_local_static_fields for some field iterations
- Merge branch 'master' into 8275731-heapshared-enum
- added exclusions needed by "java -Xshare:dump -ea -esa"
- Comments from @calvinccheung off-line
- 8275731: CDS archived enums objects are recreated at runtime
-
Changes: https://git.openjdk.java.net/jdk/pull/6653/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6653=04
Stats: 850 lines in 16 files changed: 807 ins; 2 del; 41 mod
Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v4]
On Wed, 19 Jan 2022 05:47:57 GMT, Ioi Lam wrote:
>> **Background:**
>>
>> In the Java Language, Enums can be tested for equality, so the constants in
>> an Enum type must be unique. Javac compiles an enum declaration like this:
>>
>>
>> public enum Day { SUNDAY, MONDAY ... }
>>
>>
>> to
>>
>>
>> public class Day extends java.lang.Enum {
>> public static final SUNDAY = new Day("SUNDAY");
>> public static final MONDAY = new Day("MONDAY"); ...
>> }
>>
>>
>> With CDS archived heap objects, `Day::` is executed twice: once
>> during `java -Xshare:dump`, and once during normal JVM execution. If the
>> archived heap objects references one of the Enum constants created at dump
>> time, we will violate the uniqueness requirements of the Enum constants at
>> runtime. See the test case in the description of
>> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>>
>> **Fix:**
>>
>> During -Xshare:dump, if we discovered that an Enum constant of type X is
>> archived, we archive all constants of type X. At Runtime, type X will skip
>> the normal execution of `X::`. Instead, we run
>> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X
>> that were saved at dump time.
>>
>> This is safe as we know that `X::` has no observable side effect --
>> it only creates the constants of type X, as well as the synthetic value
>> `X::$VALUES`, which cannot be observed until X is fully initialized.
>>
>> **Verification:**
>>
>> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
>> similar problems where the archived heap objects reference a static field
>> that may be recreated at runtime. There are some manual steps involved, but
>> I analyzed the potential problems found by the tool are they are all safe
>> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
>> An example trace of this tool can be found at
>> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>>
>> **Testing:**
>>
>> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
>
> Ioi Lam has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Use InstanceKlass::do_local_static_fields for some field iterations
Looks good. Minor comment below.
Also, several files with copyright year 2021 need updating.
src/hotspot/share/cds/cdsHeapVerifier.cpp line 63:
> 61: // class Bar {
> 62: // // this field is initialized in both CDS dump time and runtime.
> 63: // static final Bar bar = new Bar;
`new Bar` should be `new Bar()`?
-
Marked as reviewed by ccheung (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]
On Wed, 19 Jan 2022 05:50:50 GMT, Ioi Lam wrote:
>> I don't really know this code well enough to do a good code review. I had
>> some comments though.
>
>> I don't really know this code well enough to do a good code review. I had
>> some comments though.
>
> Hi Coleen, thanks for taking a look.
>
> This PR has two major parts:
>
> 1. Check for inappropriate reference to static fields. This is mainly done in
> cdsHeapVerifier.cpp. These checks don't affect the contents of the CDS
> archive. They just print out warnings if problems are found.
> 2. Special initialization of enum classes. Essentially if any instance of an
> enum class `X` is archived, then `X::` will not be executed, and
> we'll take this path instead (in instanceKlass.cpp):
>
>
> // This is needed to ensure the consistency of the archived heap objects.
> if (has_archived_enum_objs()) {
> assert(is_shared(), "must be");
> bool initialized = HeapShared::initialize_enum_klass(this, CHECK);
> if (initialized) {
> return;
> }
> }
>
> Could you check if (2) is correct?
> @iklam This pull request has been inactive for more than 4 weeks and will be
> automatically closed if another 4 weeks passes without any activity. To avoid
> this, simply add a new comment to the pull request. Feel free to ask for
> assistance if you need help with progressing this pull request towards
> integration!
keepalive
-
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]
On Mon, 17 Jan 2022 19:22:23 GMT, Coleen Phillimore wrote:
> I don't really know this code well enough to do a good code review. I had
> some comments though.
Hi Coleen, thanks for taking a look.
This PR has two major parts:
1. Check for inappropriate reference to static fields. This is mainly done in
cdsHeapVerifier.cpp. These checks don't affect the contents of the CDS archive.
They just print out warnings if problems are found.
2. Special initialization of enum classes. Essentially if any instance of an
enum class `X` is archived, then `X::` will not be executed, and we'll
take this path instead (in instanceKlass.cpp):
// This is needed to ensure the consistency of the archived heap objects.
if (has_archived_enum_objs()) {
assert(is_shared(), "must be");
bool initialized = HeapShared::initialize_enum_klass(this, CHECK);
if (initialized) {
return;
}
}
Could you check if (2) is correct?
-
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]
On Mon, 17 Jan 2022 18:36:35 GMT, Coleen Phillimore wrote:
>> Ioi Lam 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:
>>
>> - Merge branch 'master' into 8275731-heapshared-enum
>> - added exclusions needed by "java -Xshare:dump -ea -esa"
>> - Comments from @calvinccheung off-line
>> - 8275731: CDS archived enums objects are recreated at runtime
>
> src/hotspot/share/cds/cdsHeapVerifier.cpp line 165:
>
>> 163:
>> 164: ResourceMark rm;
>> 165: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) {
>
> Can this call instead
> void InstanceKlass::do_local_static_fields(void f(fieldDescriptor*, Handle,
> TRAPS), Handle mirror, TRAPS) {
> and have this next few lines in the function?
I moved the code inside a new class CDSHeapVerifier::CheckStaticFields so I can
call InstanceKlass::do_local_static_fields
> src/hotspot/share/cds/cdsHeapVerifier.cpp line 254:
>
>> 252: InstanceKlass* ik = InstanceKlass::cast(k);
>> 253: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) {
>> 254: if (!fs.access_flags().is_static()) {
>
> same here. It only saves a couple of lines but then you can have the
> function outside this large function.
You actually found a bug here. I am iterating over non-static fields and should
walk the inherited fields as well. I changed the code to call
InstanceKlass::do_nonstatic_fields()
> src/hotspot/share/cds/cdsHeapVerifier.hpp line 52:
>
>> 50: mtClassShared,
>> 51: HeapShared::oop_hash> _table;
>> 52:
>
> Is this only used inside cdsHeapVerifier? if so it should be in the .cpp
> file. There's also an ArchiveableStaticFieldInfo. Not sure how they are
> related.
This `_table` is part of the CDSHeapVerifier instance, which is stack
allocated. So I need to declare it as part of the CDSHeapVerifier class
declaration in the hpp file.
> src/hotspot/share/cds/heapShared.cpp line 433:
>
>> 431: oop mirror = k->java_mirror();
>> 432: int i = 0;
>> 433: for (JavaFieldStream fs(k); !fs.done(); fs.next()) {
>
> This seems like it should also use InstanceKlass::do_local_static_fields.
Converting this to InstanceKlass::do_nonstatic_fields() is difficult because
the loop body references 7 different variables declared outside of the loop.
One thing I tried is to add a new version of do_nonstatic_fields2() that
supports C++ lambdas. You can see my experiment from here:
https://github.com/openjdk/jdk/compare/master...iklam:lambda-for-instanceklass-do_local_static_fields2?expand=1
I changed all my new code to use the do_nonstatic_fields2() function with
lambda.
> src/hotspot/share/cds/heapShared.cpp line 482:
>
>> 480: copy_open_objects(open_regions);
>> 481:
>> 482: CDSHeapVerifier::verify();
>
> Should all this be DEBUG_ONLY ?
I changed CDSHeapVerifier::verify() to a NOT_DEBUG_RETURN function.
> src/hotspot/share/cds/heapShared.hpp line 236:
>
>> 234: oop _referrer;
>> 235: oop _obj;
>> 236: CachedOopInfo() :_subgraph_info(), _referrer(), _obj() {}
>
> Should these be initialized to nullptr? does this do this?
These three fields are initialized with the default initializer (empty
parenthesis) so they will be initialized to the null pointer.
-
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v4]
> **Background:**
>
> In the Java Language, Enums can be tested for equality, so the constants in
> an Enum type must be unique. Javac compiles an enum declaration like this:
>
>
> public enum Day { SUNDAY, MONDAY ... }
>
>
> to
>
>
> public class Day extends java.lang.Enum {
> public static final SUNDAY = new Day("SUNDAY");
> public static final MONDAY = new Day("MONDAY"); ...
> }
>
>
> With CDS archived heap objects, `Day::` is executed twice: once
> during `java -Xshare:dump`, and once during normal JVM execution. If the
> archived heap objects references one of the Enum constants created at dump
> time, we will violate the uniqueness requirements of the Enum constants at
> runtime. See the test case in the description of
> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>
> **Fix:**
>
> During -Xshare:dump, if we discovered that an Enum constant of type X is
> archived, we archive all constants of type X. At Runtime, type X will skip
> the normal execution of `X::`. Instead, we run
> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that
> were saved at dump time.
>
> This is safe as we know that `X::` has no observable side effect --
> it only creates the constants of type X, as well as the synthetic value
> `X::$VALUES`, which cannot be observed until X is fully initialized.
>
> **Verification:**
>
> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
> similar problems where the archived heap objects reference a static field
> that may be recreated at runtime. There are some manual steps involved, but I
> analyzed the potential problems found by the tool are they are all safe
> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
> An example trace of this tool can be found at
> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>
> **Testing:**
>
> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
Ioi Lam has updated the pull request incrementally with one additional commit
since the last revision:
Use InstanceKlass::do_local_static_fields for some field iterations
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6653/files
- new: https://git.openjdk.java.net/jdk/pull/6653/files/6e160057..e27d3523
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=6653=03
- incr: https://webrevs.openjdk.java.net/?repo=jdk=6653=02-03
Stats: 150 lines in 2 files changed: 82 ins; 59 del; 9 mod
Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]
On Sat, 11 Dec 2021 01:55:50 GMT, Ioi Lam wrote:
>> **Background:**
>>
>> In the Java Language, Enums can be tested for equality, so the constants in
>> an Enum type must be unique. Javac compiles an enum declaration like this:
>>
>>
>> public enum Day { SUNDAY, MONDAY ... }
>>
>>
>> to
>>
>>
>> public class Day extends java.lang.Enum {
>> public static final SUNDAY = new Day("SUNDAY");
>> public static final MONDAY = new Day("MONDAY"); ...
>> }
>>
>>
>> With CDS archived heap objects, `Day::` is executed twice: once
>> during `java -Xshare:dump`, and once during normal JVM execution. If the
>> archived heap objects references one of the Enum constants created at dump
>> time, we will violate the uniqueness requirements of the Enum constants at
>> runtime. See the test case in the description of
>> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>>
>> **Fix:**
>>
>> During -Xshare:dump, if we discovered that an Enum constant of type X is
>> archived, we archive all constants of type X. At Runtime, type X will skip
>> the normal execution of `X::`. Instead, we run
>> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X
>> that were saved at dump time.
>>
>> This is safe as we know that `X::` has no observable side effect --
>> it only creates the constants of type X, as well as the synthetic value
>> `X::$VALUES`, which cannot be observed until X is fully initialized.
>>
>> **Verification:**
>>
>> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
>> similar problems where the archived heap objects reference a static field
>> that may be recreated at runtime. There are some manual steps involved, but
>> I analyzed the potential problems found by the tool are they are all safe
>> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
>> An example trace of this tool can be found at
>> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>>
>> **Testing:**
>>
>> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
>
> Ioi Lam 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:
>
> - Merge branch 'master' into 8275731-heapshared-enum
> - added exclusions needed by "java -Xshare:dump -ea -esa"
> - Comments from @calvinccheung off-line
> - 8275731: CDS archived enums objects are recreated at runtime
I don't really know this code well enough to do a good code review. I had some
comments though.
src/hotspot/share/cds/cdsHeapVerifier.cpp line 165:
> 163:
> 164: ResourceMark rm;
> 165: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) {
Can this call instead
void InstanceKlass::do_local_static_fields(void f(fieldDescriptor*, Handle,
TRAPS), Handle mirror, TRAPS) {
and have this next few lines in the function?
src/hotspot/share/cds/cdsHeapVerifier.cpp line 254:
> 252: InstanceKlass* ik = InstanceKlass::cast(k);
> 253: for (JavaFieldStream fs(ik); !fs.done(); fs.next()) {
> 254: if (!fs.access_flags().is_static()) {
same here. It only saves a couple of lines but then you can have the function
outside this large function.
src/hotspot/share/cds/cdsHeapVerifier.hpp line 52:
> 50: mtClassShared,
> 51: HeapShared::oop_hash> _table;
> 52:
Is this only used inside cdsHeapVerifier? if so it should be in the .cpp file.
There's also an ArchiveableStaticFieldInfo. Not sure how they are related.
src/hotspot/share/cds/heapShared.cpp line 433:
> 431: oop mirror = k->java_mirror();
> 432: int i = 0;
> 433: for (JavaFieldStream fs(k); !fs.done(); fs.next()) {
This seems like it should also use InstanceKlass::do_local_static_fields.
src/hotspot/share/cds/heapShared.cpp line 482:
> 480: copy_open_objects(open_regions);
> 481:
> 482: CDSHeapVerifier::verify();
Should all this be DEBUG_ONLY ?
src/hotspot/share/cds/heapShared.hpp line 236:
> 234: oop _referrer;
> 235: oop _obj;
> 236: CachedOopInfo() :_subgraph_info(), _referrer(), _obj() {}
Should these be initialized to nullptr? does this do this?
-
PR: https://git.openjdk.java.net/jdk/pull/6653
[Ping] RFR: 8275731: CDS archived enums objects are recreated at runtime
Still looking for reviewers
Thanks
- Ioi
On 12/1/21 1:02 PM, Ioi Lam wrote:
**Background:**
In the Java Language, Enums can be tested for equality, so the constants in an
Enum type must be unique. Javac compiles an enum declaration like this:
public enum Day { SUNDAY, MONDAY ... }
to
public class Day extends java.lang.Enum {
public static final SUNDAY = new Day("SUNDAY");
public static final MONDAY = new Day("MONDAY"); ...
}
With CDS archived heap objects, `Day::` is executed twice: once during
`java -Xshare:dump`, and once during normal JVM execution. If the archived heap
objects references one of the Enum constants created at dump time, we will violate
the uniqueness requirements of the Enum constants at runtime. See the test case in
the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
**Fix:**
During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we
archive all constants of type X. At Runtime, type X will skip the normal execution of
`X::`. Instead, we run `HeapShared::initialize_enum_klass()` to
retrieve all the constants of X that were saved at dump time.
This is safe as we know that `X::` has no observable side effect -- it
only creates the constants of type X, as well as the synthetic value `X::$VALUES`,
which cannot be observed until X is fully initialized.
**Verification:**
To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
similar problems where the archived heap objects reference a static field that
may be recreated at runtime. There are some manual steps involved, but I
analyzed the potential problems found by the tool are they are all safe (after
the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example
trace of this tool can be found at
https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
**Testing:**
Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
-
Commit messages:
- 8275731: CDS archived enums objects are recreated at runtime
Changes: https://git.openjdk.java.net/jdk/pull/6653/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6653=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8275731
Stats: 829 lines in 16 files changed: 787 ins; 2 del; 40 mod
Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653
PR: https://git.openjdk.java.net/jdk/pull/6653
Re: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3]
> **Background:**
>
> In the Java Language, Enums can be tested for equality, so the constants in
> an Enum type must be unique. Javac compiles an enum declaration like this:
>
>
> public enum Day { SUNDAY, MONDAY ... }
>
>
> to
>
>
> public class Day extends java.lang.Enum {
> public static final SUNDAY = new Day("SUNDAY");
> public static final MONDAY = new Day("MONDAY"); ...
> }
>
>
> With CDS archived heap objects, `Day::` is executed twice: once
> during `java -Xshare:dump`, and once during normal JVM execution. If the
> archived heap objects references one of the Enum constants created at dump
> time, we will violate the uniqueness requirements of the Enum constants at
> runtime. See the test case in the description of
> [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
>
> **Fix:**
>
> During -Xshare:dump, if we discovered that an Enum constant of type X is
> archived, we archive all constants of type X. At Runtime, type X will skip
> the normal execution of `X::`. Instead, we run
> `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that
> were saved at dump time.
>
> This is safe as we know that `X::` has no observable side effect --
> it only creates the constants of type X, as well as the synthetic value
> `X::$VALUES`, which cannot be observed until X is fully initialized.
>
> **Verification:**
>
> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
> similar problems where the archived heap objects reference a static field
> that may be recreated at runtime. There are some manual steps involved, but I
> analyzed the potential problems found by the tool are they are all safe
> (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details.
> An example trace of this tool can be found at
> https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
>
> **Testing:**
>
> Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
Ioi Lam 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:
- Merge branch 'master' into 8275731-heapshared-enum
- added exclusions needed by "java -Xshare:dump -ea -esa"
- Comments from @calvinccheung off-line
- 8275731: CDS archived enums objects are recreated at runtime
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6653/files
- new: https://git.openjdk.java.net/jdk/pull/6653/files/df0d3f88..6e160057
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=6653=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk=6653=01-02
Stats: 24204 lines in 951 files changed: 16523 ins; 3176 del; 4505 mod
Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653
PR: https://git.openjdk.java.net/jdk/pull/6653
RFR: 8275731: CDS archived enums objects are recreated at runtime
**Background:**
In the Java Language, Enums can be tested for equality, so the constants in an
Enum type must be unique. Javac compiles an enum declaration like this:
public enum Day { SUNDAY, MONDAY ... }
to
public class Day extends java.lang.Enum {
public static final SUNDAY = new Day("SUNDAY");
public static final MONDAY = new Day("MONDAY"); ...
}
With CDS archived heap objects, `Day::` is executed twice: once during
`java -Xshare:dump`, and once during normal JVM execution. If the archived heap
objects references one of the Enum constants created at dump time, we will
violate the uniqueness requirements of the Enum constants at runtime. See the
test case in the description of
[JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731)
**Fix:**
During -Xshare:dump, if we discovered that an Enum constant of type X is
archived, we archive all constants of type X. At Runtime, type X will skip the
normal execution of `X::`. Instead, we run
`HeapShared::initialize_enum_klass()` to retrieve all the constants of X that
were saved at dump time.
This is safe as we know that `X::` has no observable side effect -- it
only creates the constants of type X, as well as the synthetic value
`X::$VALUES`, which cannot be observed until X is fully initialized.
**Verification:**
To avoid future problems, I added a new tool, CDSHeapVerifier, to look for
similar problems where the archived heap objects reference a static field that
may be recreated at runtime. There are some manual steps involved, but I
analyzed the potential problems found by the tool are they are all safe (after
the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example
trace of this tool can be found at
https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt
**Testing:**
Passed Oracle CI tiers 1-4. WIll run tier 5 as well.
-
Commit messages:
- 8275731: CDS archived enums objects are recreated at runtime
Changes: https://git.openjdk.java.net/jdk/pull/6653/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6653=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8275731
Stats: 829 lines in 16 files changed: 787 ins; 2 del; 40 mod
Patch: https://git.openjdk.java.net/jdk/pull/6653.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653
PR: https://git.openjdk.java.net/jdk/pull/6653
