RVM

Stack walking in MMTk not correctly identifying not yet obsolete methods?

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.9.1
  • Fix Version/s: 2.9.2
  • Component/s: MMTk, Runtime
  • Labels:
    None
  • Number of attachments :
    0

Description

During the stack trace in:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf.954/production/default/perf-dacapo/xalan-3GC/3/Output.txt

we get a CMID that when loaded from the compiled methods array turns out to be null. This indicates that we didn't calculate the set of active CMIDs correctly during GC and we've snipped the compiled method believing it to be obsolete.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. RVM-205 Use of obsolete methods in OSR events

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment -

This stack trace:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/commit.973/development/default/SPECjbb2005/SPECjbb2005/default/Output.txt

also seems to indicate that CMIDs are confused during stack tracing. Could this bug have been introduced by recent changes with SpecializedMethods?

Show
Ian Rogers added a comment - This stack trace: http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/commit.973/development/default/SPECjbb2005/SPECjbb2005/default/Output.txt also seems to indicate that CMIDs are confused during stack tracing. Could this bug have been introduced by recent changes with SpecializedMethods?
Hide
Permalink
Ian Rogers added a comment -

Both of these issues relate to the use of CMIDs and reclaiming them.

Show
Ian Rogers added a comment - Both of these issues relate to the use of CMIDs and reclaiming them.
Hide
Permalink
Ian Rogers added a comment -

A related issue is the sourceforge bug of 1147551.

Show
Ian Rogers added a comment - A related issue is the sourceforge bug of 1147551.
Hide
Permalink
Daniel Frampton added a comment -

Fixed in 13659.

Modifying heap objects during GC is a tricky business!

Show
Daniel Frampton added a comment - Fixed in 13659. Modifying heap objects during GC is a tricky business!
Hide
Permalink
Ian Rogers added a comment -

There's a new regression in a prototype build of DaCapo eclipse:

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32b.anu.edu.au/sanity.1434/prototype/default/dacapo/eclipse/default/Output.txt

the compiled method ID is out of range.

Show
Ian Rogers added a comment - There's a new regression in a prototype build of DaCapo eclipse: http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32b.anu.edu.au/sanity.1434/prototype/default/dacapo/eclipse/default/Output.txt the compiled method ID is out of range.
Hide
Permalink
Daniel Frampton added a comment -

This looks like an independant issue. I don't think we should get in the habit of reopening issues that might be related – we should report a new fault.

That said, my guess at this problem is that we actually increment the compiledMethodId before we grow the array, meaning that if we have a gc while growing the compiled method array we would get a bounds exception when snipping compiled methods. Should be a trivial fix.

Show
Daniel Frampton added a comment - This looks like an independant issue. I don't think we should get in the habit of reopening issues that might be related – we should report a new fault. That said, my guess at this problem is that we actually increment the compiledMethodId before we grow the array, meaning that if we have a gc while growing the compiled method array we would get a bounds exception when snipping compiled methods. Should be a trivial fix.
Hide
Permalink
Daniel Frampton added a comment -

I think this is fixed in 13785.

Show
Daniel Frampton added a comment - I think this is fixed in 13785.

People

  • Assignee:
    Daniel Frampton
    Reporter:
    Ian Rogers
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: