RFR(XS): JDK-8229375 Memory corruption in the implementation of the stack walk API
Frederic Parain
frederic.parain at oracle.com
Fri Aug 9 21:09:16 UTC 2019
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