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

8261268: LOAD_INSTANCE placeholders unneeded for parallelCapable class loaders #2469

Closed
wants to merge 2 commits into from

Conversation

@coleenp
Copy link
Contributor

@coleenp coleenp commented Feb 9, 2021

See CR for more details. This optimizes some code for class loading.
Tested with tier1-6.


Progress

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

Issue

  • JDK-8261268: LOAD_INSTANCE placeholders unneeded for parallelCapable class loaders

Reviewers

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Feb 9, 2021

👋 Welcome back coleenp! 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.

Loading

@openjdk openjdk bot added the rfr label Feb 9, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Feb 9, 2021

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

  • hotspot-runtime

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.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 9, 2021

Webrevs

Loading

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Hi Coleen,

The actual logic changes seem sound (though some of the reorganisation was a little hard to follow).

I have some comments on comments, but overall this seems okay provided all testing passes.

Thanks,
David

Loading

@@ -104,14 +104,17 @@ void PlaceholderEntry::set_threadQ(SeenThread* seenthread, PlaceholderTable::cla

// Doubly-linked list of Threads per action for class/classloader pair
// Class circularity support: links in thread before loading superclass
// bootstrapsearchpath support: links in a thread before load_instance_class
// bootstrap loader support: links in a thread before load_instance_class
Copy link
Member

@dholmes-ora dholmes-ora Feb 9, 2021

Choose a reason for hiding this comment

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

I don't think the loader is what the comment is referring to. The reference to bootstrapsearchpath relates to this comment in SD::resolve_instance_class_or_null:
// add placeholder entry to record loading instance class
// Five cases:
// All cases need to prevent modifying bootclasssearchpath
// in parallel with a classload of same classname

Loading

Copy link
Contributor Author

@coleenp coleenp Feb 9, 2021

Choose a reason for hiding this comment

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

I don't see any code that does this though. The code used to compute_loader_lock_object() and return NULL in JVMTI where it was modifying the bootclass search path. I wonder if that code should have a wait on the placeholder. I'll investigate.

Loading

Copy link
Contributor Author

@coleenp coleenp Feb 9, 2021

Choose a reason for hiding this comment

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

ClassLoader::load_class reads the bootstrapsearchpath lock free. If it's modified after it's read, then the new entry isn't found. I don't think there's a requirement for locking.

Loading

Loading
Loading
@openjdk
Copy link

@openjdk openjdk bot commented Feb 9, 2021

@coleenp 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:

8261268: LOAD_INSTANCE placeholders unneeded for parallelCapable class loaders

Reviewed-by: dholmes, iklam

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 17 new commits pushed to the master branch:

  • 699a3cd: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources
  • 05c6009: 8259656: fixpath.sh changes broke _NT_SYMBOL_PATH in RunTests.gmk
  • ef7ee3f: 8225081: Remove Telia Company CA certificate expiring in April 2021
  • 7c565f8: 8261209: isStandalone property: remove dependency on pretty-print
  • 01d9280: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath
  • a00b130: 8261356: Clean up enum G1Mark
  • becee64: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out
  • f395ee0: 8261306: ServiceLoader documentation has malformed Unicode escape
  • 8f4c15f: 8198540: Dynalink leaks memory when generating type converters
  • edd5fc8: 8261096: Convert jlink tool to use Stream.toList()
  • ... and 7 more: https://git.openjdk.java.net/jdk/compare/5d8204b169181166586823ba12bea2f76cb5ab6b...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this 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.

Loading

@openjdk openjdk bot added the ready label Feb 9, 2021
@coleenp
Copy link
Contributor Author

@coleenp coleenp commented Feb 9, 2021

The actual logic changes seem sound (though some of the reorganisation was a little hard to follow).

Unfortunately the diffs are bad because I did two things. I changed the indentation and I check for the class in the dictionary before adding the LOAD_INSTANCE placeholder for the !parallelCapable() && !bootclass case.

I have some comments on comments, but overall this seems okay provided all testing passes.
Yup, thanks!

Loading

iklam
iklam approved these changes Feb 9, 2021
Copy link
Member

@iklam iklam left a comment

LGTM

Loading

@coleenp
Copy link
Contributor Author

@coleenp coleenp commented Feb 9, 2021

Thanks Ioi. I reworded the comment we talked about offline.

  • // These class loaders lock a per-class object lock when ClassLoader.loadClass()
  • // is called. A LOAD_INSTANCE placeholder isn't used for mutual exclusion.

Loading

iklam
iklam approved these changes Feb 10, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Feb 10, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

Hi Coleen,

On 9/02/2021 11:36 pm, Coleen Phillimore wrote:

On Tue, 9 Feb 2021 12:27:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

src/hotspot/share/classfile/placeholders.cpp line 107:

105: // Doubly-linked list of Threads per action for class/classloader pair
106: // Class circularity support: links in thread before loading superclass
107: // bootstrap loader support: links in a thread before load_instance_class

I don't think the loader is what the comment is referring to. The reference to bootstrapsearchpath relates to this comment in SD::resolve_instance_class_or_null:
// add placeholder entry to record loading instance class
// Five cases:
// All cases need to prevent modifying bootclasssearchpath
// in parallel with a classload of same classname

I don't see any code that does this though. The code used to compute_loader_lock_object() and return NULL in JVMTI where it was modifying the bootclass search path. I wonder if that code should have a wait on the placeholder. I'll investigate.

ClassLoader::load_class reads the bootstrapsearchpath lock free. If it's modified after it's read, then the new entry isn't found. I don't think there's a requirement for locking.

I looked through the JDK 6 code and it has these comments connecting the
bootclass search path, but no actual code that shows any connection
between that path and the placeholder table. So it seems fine to expunge
all those comments in the placeholder and SD code.

Thanks,
David

Loading

@coleenp
Copy link
Contributor Author

@coleenp coleenp commented Feb 10, 2021

@dholmes-ora thanks for double checking the older code.
/integrate

Loading

@openjdk openjdk bot closed this Feb 10, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Feb 10, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Feb 10, 2021

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

  • a3d6e37: 8261302: NMT: Improve malloc site table hashing
  • ad54d8d: 8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings
  • 752f92b: 6211242: AreaAveragingScaleFilter(int, int): IAE is not specified
  • 3af334a: 6211257: BasicStroke.createStrokedShape(Shape): NPE is not specified
  • 4619f37: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint
  • 699a3cd: 8223188: Removed unnecessary #ifdef __cplusplus from .cpp sources
  • 05c6009: 8259656: fixpath.sh changes broke _NT_SYMBOL_PATH in RunTests.gmk
  • ef7ee3f: 8225081: Remove Telia Company CA certificate expiring in April 2021
  • 7c565f8: 8261209: isStandalone property: remove dependency on pretty-print
  • 01d9280: 8261299: Use-after-free on failure path in LinuxPackage.c, getJvmLauncherLibPath
  • ... and 12 more: https://git.openjdk.java.net/jdk/compare/5d8204b169181166586823ba12bea2f76cb5ab6b...master

Your commit was automatically rebased without conflicts.

Pushed as commit 52fc01b.

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

Loading

@coleenp coleenp deleted the more-cleanups branch Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants