RFR: 8213795: Force explicit null check on patching placeholder offset

Roman Kennke rkennke at redhat.com
Tue Nov 13 19:14:47 UTC 2018


That's actually a not-completely-trivial exercise because there are a
bunch of places and they don't actually say 'this is a placeholder for
patching offsets' they just say '-1'. I'll try to sort it out, and while
doing it maybe makes sense to replace -1 by a defined constant that can
be grepped for. Right?

Roman

> Hi Roman,
> 
> Would be nice if the comment points to C1 code which use -1 offset. In a
> future, when we forgot the context, I don't want to look through all
> Hotspot code to find where this -1 is coming from.
> 
> Thanks,
> Vladimir
> 
> On 11/13/18 7:16 AM, Roman Kennke wrote:
>> With current logic after JDK-8213199, we allow implicit null-checks in
>> the offset range [-cell_header_size;vm_page_size). When using
>> Shenandoah, cell_header_size is -8, so we allow [-8;vm_page_size).
>> Unfortunately, this disables explicit null-checks on -1 which is used as
>> placeholder for offsets to be patched in C1. This results in weird
>> asserts later and may actually crash if offset is outside of legal range
>> for implicit null-checks. We need to force explicit null checks on -1.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8213795
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8213795/webrev.00/
>>
>> Testing: tier1 and Shenandoah testing
>>
>> Can I please get a review?
>>
>> Roman
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181113/7caf04df/signature.asc>


More information about the hotspot-compiler-dev mailing list