RFR(S): 8038624:interpretedVFrame::expressions() must respect InterpreterOopMap for liveness

[Markus Grönlund]

Greetings,

 

Kindly asking for reviews for the following change:

 

Bug(s): http://bugs.openjdk.java.net/browse/JDK-8038624 

https://bugs.openjdk.java.net/browse/JDK-8038344 

 

Webrev: http://cr.openjdk.java.net/~mgronlun/8038624/webrev01/ 

 

Problem description:

 

An InterpreterOopMap for a particular bci position does not include expression/operand stack liveness info in the oop_mask/bit_mask if the bci is a call instruction, i.e. for the invoke* instructions (invokevirtual, invokespecial, invokestatic, invokedynamic, invokeinterface).

 

This leads to a discrepancy between what is actually on the expression/operand stack (given via fr().interpreter_frame_expression_stack_size()) and what is given in the liveness oop_mask/bit_mask (given via InterpreterOopMap) at a particular bci.

The code in interpretedVFrame::expressions() is currently based on information given from fr().interpreter_frame_expression_stack_size(), and will index into the retrieved oop_mask/bit_mask based on this information (expression slot nr + _max_locals). These indexes either: 

1. Fetches a 0 (since no live info at that position in the mask) if the index is low enough to still be inside the bit_mask word boundary. It will then proceed to treat the expression slot (which might be a real reference) as a T_INT (0 is a value, 1 is a reference) 

2. Indexes out of bounds for the oop_map/bit_mask (see https://bugs.openjdk.java.net/browse/JDK-8038344 ), and picks up information outside that is not related to a liveness bit mask. If that position happens to yield a 1, but the real expression slot is a value ("v"), the system can assert "(obj->is_oop()) failed: not an oop: 0x00000001"

 

Tested by running:

 

nsk/jdi/*

 

 

Other info:

 

I dislike having to create a new StackValueCollection even though I know the length is 0 and it will not be actively used. However, this pattern of always creating and returning empty objects is prevalent in this piece of code and is not easily detangled.

 

 

Thanks in advance

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140402/3145f44b/attachment.html>