vwithfield and ValueType.findWither

[Maurizio Cimadamore]

On 14/06/17 22:30, Paul Sandoz wrote:
> Thanks for the context, i was misled a little by a comment in the code :-)
>
>    //Todo: when 'vwithfield' is ready, this handle could be greatly simplified
Heh - I wrote this when we didn't fully know what vwithfield was :-)
>
> Originally i was going to propose that we patch in an instance Unsafe to the CP then we don’t need layers of method handles with bound leading arguments, thus less ceremony.
>
> Regardless i think there might be a bug in the HS code not deferring to the host class for accessibility checks (and an open question whether the DVT and/or VCC can be used as the host class).
Yep - I agree.
>
> With privateLookupIn i think a developer can get further than they could without it. But, i take your point on slightly different functionality, and on the creation of value types (not easy). Perhaps we should support both mechanisms? especially since much of what we do around value types is performance related. And on that note do we need a special MH constructor for a DVT?
If we had a MH constructor, I think there could be a bigger argument 
that the findWither as implemented now is redundantly 'unsafe'. But at 
the same time, using the word 'constructor' and 'value' in the same 
sentence is gonna be odd too, as there's no constructor so to speak in 
the DVT, so it might suggest a mental model which is not really there...

Maurizio

>
> Paul.
>
>> On 14 Jun 2017, at 14:15, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>>
>>
>> On 14/06/17 20:29, Paul Sandoz wrote:
>>> Hi,
>>>
>>> There appears enough VM support to try out the vwithfield in MVT and simplify the current implementation.
>> ValueType not using vwithfield is a deliberate move. vwithfield has some restrictions: the class doing vwithfield must be the same class as the owner of the field. In other words, it's mean to be used in the implementation of a value class, not as a general purpose opcode to set fields on values.
>>
>> This is why I settled on Unsafe.
>>> However, i am getting an IllegalAccessException from the VM, even though the class produced by MVT is anonymously defined with the DVT class as the host class (could be the VCC too?):
>>>
>>>> java.lang.IllegalAccessError: Update to non-static final field Point$Value.x attempted from a different class (Point_wither$x/467000451) than the field's declaring class
>> That's what I'm talking about :-)
>>> Should the VM be delegating access control checking to the host class in this case?
>> As I said, the check is deliberate I think. Perhaps we could workaround the check by picking the DVT as the host class and not the box class (as I think we do now). But I think ultimately we'd still  probably  attempt to do something that vwithfeld was not designed to do.
>>> Separately, the ValueType.findWither code needs to update it’s own access control checks such that only a lookup with the correct permissions (from the class or via privateLookupIn) can produce a wither MH. Again, should permission be granted if the lookup class is VCC in addition to DVT?
>> I think ValueType.findWither != vwithfield. I don't think we want to many restrictions (other than the one that you can actually access the field) - otherwise people will be unable to create the values they want (note that DVTs cannot have methods, so they cannot expose factories!)
>>
>> Maurizio
>>> Thanks,
>>> Paul.
>>>
>>>