RFR(XS): JDK-8229375 Memory corruption in the implementation of the stack walk API

[Frederic Parain]

> On Aug 9, 2019, at 16:11, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> 
> 
> On 8/9/19 12:57 PM, dean.long at oracle.com wrote:
>> Maybe it's overkill, but another option would be to auto-generate or auto-check these C++ accessors using a separate tool that reads the .class files.
>> 
> I think we had to do the manual field lookup because the hotspot-express model could support different versions of core libraries, so some fields might be missing in certain classes.
> 
> Now that hotspot is intrinsically hard wired to a specific JDK build, I think we should auto-generate these field accessors.

The tendency is to remove the use of hard-coded offsets.
So far, only 9 classes remains with hard-coded offsets:
java/lang/ref/Reference and the 8 boxing classes for primitives.
These classes have hard-coded offsets because code depending on
these offsets is generated before the classes are loaded.

Field layouts are not guaranteed. Hotspot has even an option
that could generate different layouts (FieldsAllocationStyle).
Hard-coded offset are a huge pain in field layout computation,
because they require special handling (and are brittle by nature).

Coleen just marked FieldsAllocationStyle for deprecation, but 
it is still available today.

With project Valhalla coming in, field layouts will become
more complex, because of field flattening. As the importance
of field layout grows, I expect that we would want to implement
different strategies depending of user input. The less
assumptions about offsets, the easier it is to implement a
layout strategy.

Future of field layout computation could look like this:

http://cr.openjdk.java.net/~fparain/jdk_layout/webrev.00/

(port of Valhalla code to JDK asked by Coleen).

Fred


> 
>> dl
>> 
>> On 8/9/19 12:51 PM, dean.long at oracle.com wrote:
>>> It would be nice if we could detect problems like this automatically.  Since this is an oop, we could figure out the field type at the given offset (slow).  Or keep around the type information that was given to STACKFRAMEINFO_FIELDS_DO and compute a {offset, size} tuple instead.
>>> 
>>> dl
>>> 
>>> On 8/9/19 9:54 AM, Frederic Parain wrote:
>>>> Greetings,
>>>> 
>>>> please review this one line change to fix a memory corruption
>>>> issue in the stack walk API implementation.
>>>> 
>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8229375
>>>> Webrev: http://cr.openjdk.java.net/~fparain/8229375/webrev.00/index.html
>>>> 
>>>> Thank you,
>>>> 
>>>> Fred
>>>> 
>>> 
>> 
>