vwithfield and ValueType.findWither

David Simms david.simms at oracle.com
Mon Jun 19 09:33:36 UTC 2017

Re: "HotSpot code accessibility checks"

I did play around with explicitly opening up access from the VCC:


(MethodHandleBuilder "vdefault" and "vwithfield" parts are already in)

This code is specific to the VCC / DVT relationship, and was a bit of a 
hack to start the conversation some time back. We were happy living with 
the unsafe hack for the time being, but I would prefer to use stop using 
said work-around.

I believe Dan's suggestion "Access restriction for vwithfield" on the 
design mail list is more practical (package private)...let's follow that 
conversation and get the JVMS definition right.

Main points from previous discussions:

  * Original "vnew" proposal took all fields as stack args, all the time.
      o Hard to optimize, inefficient for value where most fields are
      o "vwithfield" easier to optimize (possible to elide COW
        semantics, efficiently change only required fields)
  * Allow the user-code to enforce invariant values
      o Able to implement "never publish (vastore, putfield) 'Foo' value
        with any zero fields"
      o Access restrictions from VCC or package private ?

Recent changes to the ValueType API accepting MH lookup now gives a few 
more options to the user.


On 15/06/17 19:32, Paul Sandoz wrote:
> 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

More information about the valhalla-dev mailing list