vwithfield and ValueType.findWither

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Jun 14 21:15:55 UTC 2017

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!)

> Thanks,
> Paul.

More information about the valhalla-dev mailing list