vwithfield and ValueType.findWither

[Paul Sandoz]

Hi Fred,

Do you know where in the HotSpot code accessibility checks are performed for vwithfield? We need to fix those checks for Unsafe defined anonymous classes to defer to the host class (and if a suitable VCC or DVT then access should be granted).

Paul.

> On 15 Jun 2017, at 07:06, Frederic Parain <frederic.parain at oracle.com> wrote:
> 
> 
> 
> On 06/15/2017 05:36 AM, Maurizio Cimadamore wrote:
>> 
>> 
>> On 15/06/17 09:46, John Rose wrote:
>>> On Jun 14, 2017, at 2:20 PM, Maurizio Cimadamore
>>> <maurizio.cimadamore at oracle.com> wrote:
>>>> Another possible story is that we always create values through the
>>>> VCC constructor, and then unbox. If we think we're happy with that,
>>>> that might be a fine choice too.
>>> That's not a bad story for the JIT with aggressive scalarization,
>>> and was my first idea about this, but it is painful in the interpreter.
>>> 
>> In which ways it's bad for the interpreter? Note that the current
>> implementation of the 'modified' findWither will do just that:
>> 
>> * box incoming value
>> * set field (with Unsafe.putXYZ)
>> * unbox resulting reference back to a value
>> 
>> So, it seems to me that, to set 5 fields, the above idiom will do
>> box/unbox 5 times, while if we just create a VCC with the fields we want
>> and then unbox, that's just one unboxing step.
>> 
>> What am I missing?
> 
> With the vwithfield bytecode, the interpreter can avoid Java heap
> allocations, with the box/Unsafe/unbox it cannot.
> 
> Just a performance/memory issue.
> 
> Fred