RFR 8158850: [JVMCI] be more precise when enforcing OopMapValue encoding limitations

[Tom Rodriguez]

Good point.  I decided it made more sense to move it into CompilerToVM::Data like other values computed for the HotSpotVMConfig.  I also merged against latest hs-comp which eliminated by VMConfig changes.  Updated in place.

tom

> On Jun 16, 2016, at 12:49 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Field's name should start with '_':
> 
> +  static int max_oop_map_stack_offset;
> 
> Otherwise looks good.
> 
> Thanks,
> Vladimir
> 
> On 6/16/16 12:34 PM, Tom Rodriguez wrote:
>> Any takers?
>> 
>> tom
>> 
>>> On Jun 13, 2016, at 5:26 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~never/8158850/webrev
>>> 
>>> The encoding used by OopMapValue puts a limit on the offset in the frame that can hold an oop.  Previously this was enforced by setting a limit on the actual frame size but that value wasn’t accurate.  It also sets an arbitrary limit on the total size of a frame, even if the encoding limits aren’t reached.  Instead JVMCI should export the max offset that can be encoded and will throw an error if that offset is used.  The relationship between the max offset and the encoding limits is computed from OopMapValue and checked by asserts.  I also added a test that verifies the limits.  Tested with jtreg test and with Graal based tests.
>>> 
>>> tom
>>