RFR (XS) CR 8015493: runtime/contended/OopMaps.java fails with OutOfMemory

Aleksey Shipilev aleksey.shipilev at oracle.com
Tue May 28 08:39:48 PDT 2013


>> On 05/28/2013 06:09 PM, Aleksey Shipilev wrote:
>>> Hi,
>>>
>>> This is the tiny fix for the nightly failure on the regression test:
>>>    http://cr.openjdk.java.net/~shade/8015493/webrev.01/

The new webrev is here:
  http://cr.openjdk.java.net/~shade/8015493/webrev.02/

Changeset is available at request. (I think only Daniel counts as
reviewer so far; do trivial test changes require two reviewers?).

>>> Reasons:
>>>    Due to the nature of test, R1 instance size is large (1880 bytes on
>>>    my Linux x86_64), and we allocate 100K of them during the test. We
>>>    do that in the test because we want to have some of the objects
>>>    pushed through the garbage collection to catch unusual behavior.
>>>    The flip side is, we have ~200 Mb heap allocated just for R1 objects.
>>>    While it works nicely on some platforms, the default heap sizes
>>>    may fail the test. This makes the issue the test bug.
>>>
>>> Fix:
>>>    Allocate 10K of R1 objects in the test, require -Xmx128m. The target
>>>    heap occupancy for the test is then ~20Mb, so we have lots of
>>>    headroom for all platforms.
>>>
>>> Testing:
>>>   (this falls into my definition of being trivial, so:)
>>>   * jtreg: runtime/contended/ on Linux x86_64
>>>   * manual testing with 8015270 partially reverted, OopMaps fails on
>>> Linux x86_64, as would anyone expect for a good regression test
>>>   * also looked through the code for other runtime/contended regression
>>> tests, and those seem unaffected

 + validated runtime/contended/ regression tests on
  {i586, x86_64}*{fastdebug,product}*{linux, solaris, windows, macosx}

-Aleskey.


More information about the hotspot-runtime-dev mailing list