RFR: 8040935: -XX:+AggressiveOpts broken: GC triggered before VM initialization completed on several tests
stefan.johansson at oracle.com
Wed Jan 14 23:49:21 UTC 2015
On 2015-01-14 19:13, Kim Barrett wrote:
> On Jan 12, 2015, at 5:01 AM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>> Please review this testfix to avoid the following issue:
>> Making the test a driver test to avoid dealing with externally specified flags. One problematic flag is AggressiveOpts, it causes the VM to allocate more stuff during startup and that together with UseNUMA the eden space gets to little to handle all startup allocations. This will in turn lead to a GC being triggered before initialization is finished, and because of that failing the test.
>> * Tested via JPRT
> Summary: Changed test to not be affected by external options.
> I'm not sure I like this approach to resolving the bug. I think it
> results in many potentially interesting configurations never being
> tested, e.g. this tests with one and only one GC, the default GC. It
> ignores the nightly build cycling through various configurations to
> increase test coverage.
Thanks for taking a look at this. I see your point and think we should
do something better. The test was originally written to test a specific
regression we had when starting with -Xmx8m and -XX:+UseNUMA with the
default collector, but that doesn't mean we shouldn't test it for the
others as well. I'm not sure if we have any NUMA support for the other
collectors today, but no harm in testing that the option doesn't cause
I see two ways of improving the coverage, one would be to use @requires
to say that AggressiveOpts can't be true, but that will still leave the
possibility to set other options that might push us over the limit of
allocations during startup. The other way would be to extend the test to
run with all collectors explicitly, but ignore any options passed in.
This would of course still have less coverage than today, but at least
all collectors would be covered.
I would prefer the second one, it would be robust and the coverage would
More information about the hotspot-gc-dev