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

Java 9,10,11 slow to start on zLinux #2388

Closed
pshipton opened this issue Jul 13, 2018 · 7 comments
Closed

Java 9,10,11 slow to start on zLinux #2388

pshipton opened this issue Jul 13, 2018 · 7 comments

Comments

@pshipton
Copy link
Member

pshipton commented Jul 13, 2018

Java 9,10,11 are slow to start on zLinux.

This problem seems to be the cause of #2329.

The default -Xmx for Java 9 and later is 25% of the physical memory. Startup time varies, but on a zLinux machine with 64GB, startup time without specifying -Xmx can be a second or more. Explicitly set -Xmx512m and its much faster. The time varies from run to run, and OS to OS. Explicitly setting an -Xmx which is equivalent to the default may also speed up the startup time.

@pshipton pshipton added this to the Release 0.10.0 milestone Jul 13, 2018
@pshipton pshipton changed the title Java 9,10,11 slow to start on Linux Java 9,10,11 slow to start on zLinux Jul 13, 2018
@pshipton
Copy link
Member Author

pshipton commented Jul 13, 2018

May also affect other Linux platforms to some extent. The problem was originally mentioned in #1888.

@charliegracie
Copy link
Contributor

@pshipton can you please show an example of where specifying the exact same value for -Xmx as what would be picked without one shows a difference in startup performance? I would like to see verbose:gc logs to verify that the maximum and initial heap values are exactly the same byte value.

@pshipton
Copy link
Member Author

Double checked, setting an -Xmx which is equivalent to the default does not speed up the startup time.

@keithc-ca keithc-ca self-assigned this Jul 17, 2018
@pshipton
Copy link
Member Author

One of the problems is fixed by eclipse-omr/omr#2743, however there is still a problem outstanding. The QUICK memory allocation algorithm can fail to find a suitable candidate but then it falls back to a brute force search which also won't find any suitable memory and can be very slow.

@pshipton
Copy link
Member Author

The remaining problem appears resolved by eclipse-omr/omr#2796.
See #2329 for details.

@keithc-ca
Copy link
Contributor

Fixed via eclipse-omr/omr#2796.

@pshipton
Copy link
Member Author

For the record, eclipse-openj9/openj9-omr#12 merged eclipse-omr/omr#2796 to the v0.9.0-release branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants