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

Mandy Chung mandy.chung at oracle.com
Fri Aug 9 21:52:49 UTC 2019


+1

Mandy

On 8/9/19 2:09 PM, Frederic Parain wrote:
> Yes to all your comments below.
> Here’s the new webrev:
>
> http://cr.openjdk.java.net/~fparain/8229375/webrev.01/index.html
>
> Thank you,
>
> Fred
>
>
>> On Aug 9, 2019, at 15:50, Mandy Chung <mandy.chung at oracle.com> wrote:
>>
>> On 8/9/19 11:24 AM, Frederic Parain wrote:
>>> I’d prefer the assert solution based on the JVMS definition of method’s length:
>> This is reasonable.
>>> code_length
>>> The value of the code_length item gives the number of bytes in the code array for this method.
>>> The value of code_length must be greater than zero (as the code array must not be empty) and less than 65536.
>>>
>>> Which would produce something like this:
>>>
>>> void java_lang_StackFrameInfo::set_bci(oop element, short value) {
>> I think you meant set_bci(oop element, int value)
>>>    assert(value >= 0 && value < 65536, “bci outside of valid range”);
>>>    element->short_field_put(_bci_offset, value);
>> This would then need a cast "(jshort)value"
>>> }
>>>
>>> What do yo think?
>> Mandy



More information about the hotspot-runtime-dev mailing list