Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp #2246

Conversation

iklam
Copy link
Member

@iklam iklam commented Jan 26, 2021

The "well-known classes" API in systemDictionary.hpp is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other.

The proposed API follows the existing pattern of accessing known symbols/intrinsics in vmSymbols.hpp and vmIntrinsics.hpp:

#include "classfile/vmClasses.hpp"
#include "classfile/vmIntrinsics.hpp"
#include "classfile/vmSymbols.hpp" // NEW

Symbol* s = vmSymbols::java_lang_Object();
vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial;
Klass* k = vmClasses::Object_klass(); // NEW

Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like SystemDictionary::Object_klass() to vmClasses::Object_klass(). That will be done in a subtask (JDK-8260471 -- preliminary webrev).

Within this RFE, we temporarily subclass SystemDictionary from vmClasses, so SystemDictionary::Object_klass() will continue to work.

Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2246/head:pull/2246
$ git checkout pull/2246

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 26, 2021

👋 Welcome back iklam! 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
Copy link

openjdk bot commented Jan 26, 2021

@iklam The following labels will be automatically applied to this pull request:

  • hotspot
  • serviceability

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

@openjdk openjdk bot added serviceability serviceability-dev@openjdk.org hotspot hotspot-dev@openjdk.org labels Jan 26, 2021
@iklam
Copy link
Member Author

iklam commented Jan 26, 2021

/label remove serviceability

@openjdk openjdk bot removed the serviceability serviceability-dev@openjdk.org label Jan 26, 2021
@openjdk
Copy link

openjdk bot commented Jan 26, 2021

@iklam
The serviceability label was successfully removed.

@iklam iklam changed the title 8260467: move well known klasses out of system dictionary 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp Jan 26, 2021
@iklam iklam marked this pull request as ready for review January 26, 2021 23:48
@openjdk openjdk bot added the rfr Pull request is ready for review label Jan 26, 2021
@mlbridge
Copy link

mlbridge bot commented Jan 26, 2021

Webrevs

@iklam
Copy link
Member Author

iklam commented Jan 27, 2021

The name vmClasses is in lowerCamelCase, which is a deviation from the rest of the HotSpot code, where most classes have UpperCamelCase names. However, vmClasses and vmSymbols are often used together, like the following, so a consistent look would be nice:

JavaCalls::call_static(&result,
   vmClasses::MethodHandleNatives_klass(),
   vmSymbols::linkMethodHandleConstant_name(),
   vmSymbols::linkMethodHandleConstant_signature(),
   &args, CHECK_(empty));

@mlbridge
Copy link

mlbridge bot commented Jan 27, 2021

Mailing list message from Coleen Phillimore on hotspot-dev:

On 1/26/21 7:04 PM, Ioi Lam wrote:

On Tue, 26 Jan 2021 23:13:33 GMT, Ioi Lam <iklam at openjdk.org> wrote:

The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other.

The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108):

#include "classfile/vmClasses.hpp"
#include "classfile/vmIntrinsics.hpp"
#include "classfile/vmSymbols.hpp" // NEW

Symbol* s = vmSymbols::java_lang_Object();
vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial;
Klass* k = vmClasses::Object_klass(); // NEW

Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)).

Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work.

Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero.
The name `vmClasses` is in `lowerCamelCase`, which is a deviation from the rest of the HotSpot code, where most classes have `UpperCamelCase` names. However, `vmClasses` and `vmSymbols` are often used together, like the following, so a consistent look would be nice:

JavaCalls::call_static(&result,
vmClasses::MethodHandleNatives_klass(),
vmSymbols::linkMethodHandleConstant_name(),
vmSymbols::linkMethodHandleConstant_signature(),
&args, CHECK_(empty));

I agree!

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Ioi,

This first step at refactoring and renaming looks good.

Only one comment below.

Thanks,
David


#if INCLUDE_CDS

void vmClasses::resolve_shared_class(InstanceKlass* klass, ClassLoaderData* loader_data, Handle domain, TRAPS) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't at all obvious to me why this functionality was relocated. I don't see anything vmClasses related in here. ??

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vmClasses::resolve_shared_class() is a private method and is called from here:

bool vmClasses::resolve(VMClassID id, TRAPS) {
  InstanceKlass** klassp = &_klasses[as_int(id)];
...
    InstanceKlass* k = *klassp;
    resolve_shared_class(k, ....);  <---- HERE
}

Maybe the function name is not clear enough. It's meant to "resolve a vmClass from the CDS archive". It used to be the (even more confusingly named) SystemDictionary::quick_resolve() method.

@openjdk
Copy link

openjdk bot commented Jan 27, 2021

@iklam This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp

Reviewed-by: dholmes, coleenp

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jan 27, 2021
@mlbridge
Copy link

mlbridge bot commented Jan 27, 2021

Mailing list message from David Holmes on hotspot-dev:

On 27/01/2021 5:52 pm, Ioi Lam wrote:

On Wed, 27 Jan 2021 06:27:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

The "well-known classes" API in [systemDictionary.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/systemDictionary.hpp#L103) is for accessing a fixed set of classes defined by the bootstrap loader. The rest of systemDictionary.hpp is for finding/defining arbitrary classes in arbitrary class loaders. For modularity, we should separate these two sets of APIs, and make them independent of each other.

The proposed API follows the existing pattern of accessing known symbols/intrinsics in [vmSymbols.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmSymbols.hpp#L53) and [vmIntrinsics.hpp](https://github.com/openjdk/jdk/blob/19b6f61bd2f49f06ef6b8e9b6ecd2fd910070035/src/hotspot/share/classfile/vmIntrinsics.hpp#L108):

#include "classfile/vmClasses.hpp"
#include "classfile/vmIntrinsics.hpp"
#include "classfile/vmSymbols.hpp" // NEW

Symbol* s = vmSymbols::java_lang_Object();
vmIntrinsics::ID id = vmIntrinsics::_linkToSpecial;
Klass* k = vmClasses::Object_klass(); // NEW

Note: to help the review process and limit the amount of boiler-place changes, within this RFE, we do not change existing calls like `SystemDictionary::Object_klass()` to `vmClasses::Object_klass()`. That will be done in a subtask ([JDK-8260471](https://bugs.openjdk.java.net/browse/JDK-8260471) -- [preliminary webrev](http://cr.openjdk.java.net/~iklam/jdk17/8260471-decouple-vmClasses-and-SystemDictionary/)).

Within this RFE, we temporarily subclass `SystemDictionary` from `vmClasses`, so `SystemDictionary::Object_klass()` will continue to work.

Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero.

src/hotspot/share/classfile/vmClasses.cpp line 219:

217: #if INCLUDE_CDS
218:
219: void vmClasses::resolve_shared_class(InstanceKlass* klass, ClassLoaderData* loader_data, Handle domain, TRAPS) {

It isn't at all obvious to me why this functionality was relocated. I don't see anything vmClasses related in here. ??

`vmClasses::resolve_shared_class()` is a private method and is called from here:

bool vmClasses::resolve(VMClassID id, TRAPS) {
InstanceKlass** klassp = &_klasses[as_int(id)];
...
InstanceKlass* k = *klassp;
resolve_shared_class(k, ....); <---- HERE
}

Maybe the function name is not clear enough. It's meant to "resolve a vmClass from the CDS archive". It used to be the (even more confusingly named) `SystemDictionary::quick_resolve()` method.

Thanks for clarifying - the fact it has a single caller was not clear.

David

Copy link
Contributor

@coleenp coleenp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not consolidate vmClassMacros.hpp into vmClassID.hpp ?

@iklam
Copy link
Member Author

iklam commented Jan 27, 2021

Why not consolidate vmClassMacros.hpp into vmClassID.hpp ?

ciEnv.hpp uses the VM_CLASSES_DO macro, but does not use anything inside vmClassID.hpp. As a result, vmClassMacros.hpp is included by 468 .o files, but vmClassID.hpp is included only by 318 files.

Copy link
Contributor

@coleenp coleenp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok!

@iklam
Copy link
Member Author

iklam commented Jan 28, 2021

Thanks @coleenp and @dholmes-ora for the review!
/integrate

@openjdk openjdk bot closed this Jan 28, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 28, 2021
@openjdk
Copy link

openjdk bot commented Jan 28, 2021

@iklam Since your change was applied there have been 2 commits pushed to the master branch:

  • 62ffe75: Merge
  • e28e111: 8260370: C2: LoopLimit node is not eliminated

Your commit was automatically rebased without conflicts.

Pushed as commit 396a496.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org integrated Pull request has been integrated
3 participants