Loading...

XML

Word

Printable

Type: Enhancement
Resolution: Fixed
Priority: P4
Fix Version/s: hs22
Affects Version/s: hs18, hs21
Component/s: hotspot
Labels:
- gc-g1
- gc-largeheap

Subcomponent:
gc
Resolved In Build:
b05
CPU:

generic
OS:

generic
Verification:
Verified

Issue	Fix Version	Assignee	Priority	Status	Resolution	Resolved In Build
JDK-2215439	8	Bengt Rutisson	P4	Resolved	Fixed	b08
JDK-2214850	7u2	Bengt Rutisson	P4	Closed	Fixed	b08

Right now, when the young gen size auto-tuning in G1 is enabled (with UseAdaptiveSizePolicy), G1 sets the young gen size to what the ergonomic code calculates and does not obey and min / max bounds (even if NewSize / MaxNewSize have been explicitly set).

We should introduce min / max young gen size limits. The defaults of those limits should be very aggressive (e.g., maybe 1-2 regions for min, 50% of the heap for max). Those limits should be also settable by the user with NewSize / MaxNewSize.

backported by

JDK-2215439 G1: introduce min / max young gen size bounds

Resolved

JDK-2214850 G1: introduce min / max young gen size bounds

Closed

duplicates

JDK-7026339 G1: support the -Xmn flag better

Closed

relates to

JDK-7084509 G1: fix inconsistencies and mistakes in the young list target length calculations

Closed

JDK-6928065 G1: use existing command line parameters to set the young generation size

Closed

JDK-7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx

Closed

JDK-7022456 G1: Significant memory footprint increase compared to other collectors during application startup

Closed

(2 relates to)

Assignee:: Bengt Rutisson (Inactive)

Reporter:: Tony Printezis

Votes:: 0 Vote for this issue

Watchers:: 1 Start watching this issue

Created:: 2010-02-25 08:43

Updated:: 2013-10-04 02:06

Resolved:: 2011-11-27 21:42

Imported:: 17/Sep/12 3:31 AM

Indexed:: 19/Jul/12 7:35 PM

Details

Backports

Description

Attachments

Issue Links

Activity

People

Dates