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

[dean.long at oracle.com]

I forgot that we already have a solution in JVMCI for the offset lookup 
and signature mismatch problem.  See the macros in jvmciJavaClasses.hpp 
and jvmciJavaClasses.cpp.  Maybe we should refactor that code so it can 
be used for non-jvmci classes.

dl

On 8/9/19 2:03 PM, Frederic Parain wrote:
>
>> 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
>>>>>