RVM

Problem with CMID/stackframe mapping in reflection

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 3.0.1
  • Fix Version/s: 3.1.4
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

Since the reflection changes to use bytecode generation, we've been getting a low probability crash during GC stack scanning where the stackwalker thinks we should be in
org/jikesrvm/runtime/Reflection;.invoke, but the actual ip is somewhere else.

For one example, see:

http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/sanity-ppc32/5008/FullAdaptiveMarkSweep/default/jBYTEmark/jBYTEmark/default/Output.txt

This crash happens in a few tests per sanity run. No correlation to test or jikes rvm configuration, but the stack trace/error message is always from the stackwalker trying to map the cmid it has found in the stack frame, finding that the cmid is for Reflection.invoke, but that the actual ip is somewhere else.

Activity

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

This problem is still occurring even after r14934, for example:

http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/sanity-ppc32/5055/BaseBaseMarkSweep/default/dacapo/eclipse/default/Output.txt

I believe the problem lies with the stack walking on PPC. We're getting the CMID for the frame below the current frame rather than the current frame. Maybe I can disprove this by finding the same failure on IA32. The fault could be that "this" for the reflective method call is null and the exception being generated at this point is legitimate.

Show
Ian Rogers added a comment - This problem is still occurring even after r14934, for example: http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/sanity-ppc32/5055/BaseBaseMarkSweep/default/dacapo/eclipse/default/Output.txt I believe the problem lies with the stack walking on PPC. We're getting the CMID for the frame below the current frame rather than the current frame. Maybe I can disprove this by finding the same failure on IA32. The fault could be that "this" for the reflective method call is null and the exception being generated at this point is legitimate.
Hide
Permalink
David Grove added a comment -

intermittent ppc-only failures could also be a result of having failed to follow the proper sequence to synch dcache/icache. Does the new reflection impl rely on code patching at all?

Show
David Grove added a comment - intermittent ppc-only failures could also be a result of having failed to follow the proper sequence to synch dcache/icache. Does the new reflection impl rely on code patching at all?
Hide
Permalink
David Grove added a comment -

Also happens on BaseBase images, for example: http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/sanity-ppc32/5055/BaseBaseMarkSweep/default/dacapo/eclipse

So interactions with opt compiler, OSR, and/or AOS can be ruled out.

Show
David Grove added a comment - Also happens on BaseBase images, for example: http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/sanity-ppc32/5055/BaseBaseMarkSweep/default/dacapo/eclipse So interactions with opt compiler, OSR, and/or AOS can be ruled out.
Hide
Permalink
Ian Rogers added a comment -

The new reflection works by creating an array of bytes/bytecodes and wrapping them in a normal method. The method is then attached to a class that is descended from ReflectionBase (it's name incorporates the ID of the method, so we can always find the class to invoke a method just from its ID), the method overriding ReflectionBase.invoke. The advantage of tackling the methods in this way is that by generating bytecodes the worries about boxing and unboxing become much easier and we should be able to fold away much of the dispatch (we don't even have to disable GC during the dispatch). Previously we couldn't do this as we had to box everything up in word arrays for the out of line invocation to then unbox. As its working at the level of bytecodes the isync/dsync issue shouldn't be relevant. Generating the bytecodes does mean that things like the field arrays, line number tables are just empty stubs. It could be an untested route for class resolution - hence r14934 forcing resolution just after creating/loading the bytecodes. What should happen is that the first time the bytecodes are invoked by getting the method invoker (RVMMethod.getInvoker), creating the invoker object should resolve the class, we compile them through the normal lazy compilation trampoline.

I'm curious as to whether this is a PPC stack walking bug as I see similar stack traces in other scenarios, e.g.:

http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/sanity-ppc32/5055/FullAdaptiveGenImmix/default/dacapo/eclipse/default/Output.txt

Show
Ian Rogers added a comment - The new reflection works by creating an array of bytes/bytecodes and wrapping them in a normal method. The method is then attached to a class that is descended from ReflectionBase (it's name incorporates the ID of the method, so we can always find the class to invoke a method just from its ID), the method overriding ReflectionBase.invoke. The advantage of tackling the methods in this way is that by generating bytecodes the worries about boxing and unboxing become much easier and we should be able to fold away much of the dispatch (we don't even have to disable GC during the dispatch). Previously we couldn't do this as we had to box everything up in word arrays for the out of line invocation to then unbox. As its working at the level of bytecodes the isync/dsync issue shouldn't be relevant. Generating the bytecodes does mean that things like the field arrays, line number tables are just empty stubs. It could be an untested route for class resolution - hence r14934 forcing resolution just after creating/loading the bytecodes. What should happen is that the first time the bytecodes are invoked by getting the method invoker (RVMMethod.getInvoker), creating the invoker object should resolve the class, we compile them through the normal lazy compilation trampoline. I'm curious as to whether this is a PPC stack walking bug as I see similar stack traces in other scenarios, e.g.: http://jikesrvm.anu.edu.au/cattrack/results/piccolo.watson.ibm.com/sanity-ppc32/5055/FullAdaptiveGenImmix/default/dacapo/eclipse/default/Output.txt
Hide
Permalink
David Grove added a comment -

Still happening. For example: http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/core-ppc64/5307/production/Measure_Compilation_Opt_1/SPECjvm98/_202_jess

Show
David Grove added a comment - Still happening. For example: http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/core-ppc64/5307/production/Measure_Compilation_Opt_1/SPECjvm98/_202_jess
Hide
Permalink
Ian Rogers added a comment -

Still happening:
http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/core-ppc32/6029/development/default/dacapo/xalan/default/Output.txt

Show
Ian Rogers added a comment - Still happening: http://jikesrvm.anu.edu.au/cattrack/results/piano.watson.ibm.com/core-ppc32/6029/development/default/dacapo/xalan/default/Output.txt
Hide
Permalink
David Grove added a comment -

Defer to 3.1.1

Show
David Grove added a comment - Defer to 3.1.1
Hide
Permalink
David Grove added a comment -

bulk defer open issues to 3.1.2

Show
David Grove added a comment - bulk defer open issues to 3.1.2
Hide
Permalink
David Grove added a comment -

Bulk defer to 3.1.3; not essential to address for 3.1.2.

Show
David Grove added a comment - Bulk defer to 3.1.3; not essential to address for 3.1.2.
Hide
Permalink
David Grove added a comment -

bulk defer issues to 3.1.4

Show
David Grove added a comment - bulk defer issues to 3.1.4

People

  • Assignee:
    Unassigned
    Reporter:
    David Grove
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: