8350097: Make Compilation::current() and Compile::current() safer

[tstuefe]

Somewhat trivial.

I recently hunted a bug for an hour until I realized that I had accessed ciEnv::compiler_data() as C2 Compile when, in fact, it was C1 Compilation. Stupid mistake, but an assert is easy to do and saves time.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8350097: Make Compilation::current() and Compile::current() safer (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23635/head:pull/23635
$ git checkout pull/23635

Update a local copy of the PR:
$ git checkout pull/23635
$ git pull https://git.openjdk.org/jdk.git pull/23635/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23635

View PR using the GUI difftool:
$ git pr show -t 23635

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23635.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@tstuefe The following label will be automatically applied to this pull request:

• hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (b4b1bbd3)
• 00: Full (a103b455)

[shipilev]

DEBUG_ONLY lives in utilities/macros.hpp, include that one directly?

[shipilev]

So, can it be just some sort of:

    assert(CompilerThread::current()->compiler()->is_c1(), "sanity");

...without any other changes in ciEnv?

[shipilev]

Context: I think ciEnv is pretty compiler-agnostic, and it would be better to avoid exposing the fact C1/C2 exist to that interface, even if only for asserts. Seems cleaner to check that we are calling Compilation::current() from C1 and Compile::current() from C2.

[vnkozlov]

I agree with Aleksey here.

[tstuefe]

Yes, I like this too. Simpler. Okay, I try that.

[dean-long]

If we derive C2 Compile and C1 Compilation from a common superclass, then ciEnv::compiler_data() could return that superclass and self-identify using a type field or virtual function. When looking into how we handle failure messages and how complicated it is, I thought moving some fields into a common superclass would be useful. Eventually we could even look into making ciEnv the common superclass, because the lifetimes are almost identical.

[tstuefe]

If we derive C2 Compile and C1 Compilation from a common superclass, then ciEnv::compiler_data() could return that superclass and self-identify using a type field or virtual function. When looking into how we handle failure messages and how complicated it is, I thought moving some fields into a common superclass would be useful. Eventually we could even look into making ciEnv the common superclass, because the lifetimes are almost identical.

I thought about that, but Compile inherits from Phase, so any common superclass becomes one of Phase, too. I did not want to change the inheritance structure to deal with such a tiny problem.

[dean-long]

Since the callers already need to know which compiler they are asking about, I don't see the value in forcing void* through a single interface. How about we improve things by replacing compiler_data with c1_compiler_data() and c2_compiler_data()?

[bridgekeeper]

@tstuefe 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!

[bridgekeeper]

@tstuefe This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.