RFR (XS): 8027756: assert(!hr->isHumongous()) failed: code root in humongous region? (P2-JDK8!)
jon.masamitsu at oracle.com
Wed Nov 6 04:11:13 UTC 2013
I should also have said that the changes look good.
On 11/5/2013 4:00 PM, Jon Masamitsu wrote:
> Do you think there would be value in printing out the
> region address in the cases where the assertion fails?
Your call as to whether it's worth printing the heap region.
> Does your new test case fail with both the client and
> server compilesr?
Question relates to whether you want to specify the JIT
used when running the test.
> On 11/5/2013 5:46 AM, Thomas Schatzl wrote:
>> Hi all,
>> can I get quick reviews for the following small changes?
>> The patchset fixes wrong assertions that assume that references to
>> humongous/large objects cannot be embedded into the code stream. They
>> This is not true, and in the failing (existing) test case just that
>> The fix is to just change all these wrong assertions to check whether
>> the region we want to add the code root to is a humongous continuation:
>> that really should not occur as they do not contain an object header.
>> Note that there is a similar assertions with the same conditions in e.g.
>> MigrateCodeRootsHeapRegionClosure::doHeapRegion() - however this one
>> checks a different situation: there should be no migration of code roots
>> because (currently) large objects can never move.
>> The original reasons for adding this assertion, and why this assertion
>> only triggers just now (the code has been in for a few months) are
>> unknown. I will try to find out what change (possibly in the compiler)
>> triggered this.
>> The changeset also adds a new test in addition to the original one that
>> particularly targets most reasons why the assertion failed before:
>> - when adding a new code root to a humongous region
>> - when removing a new code root to a humongous region
>> - during verification (does anybody know why
>> G1VerifyHeapRegionCodeRoots is false by default?)
>> - strong code roots root marking (in anticipation of class unloading
>> during concurrent marking)
>> jprt, manual invocation of the failing test (verifying that without the
>> change the assertion triggers, and does not with the patch), new test
More information about the hotspot-gc-dev