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