RFR (XS): [MVT] Support Q-types in MHs.constant()
paul.sandoz at oracle.com
Wed Jul 12 15:22:29 UTC 2017
> On 12 Jul 2017, at 06:35, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> On 12/07/17 13:54, Vladimir Ivanov wrote:
>> Though it looks attractive at first, I don't think it'll take us too far.
>> j.l.i API is full of method handle combinators which should properly handle DVTs. If there's a separate place for DVT-capable combinators, then the combinators (all of them?) should be duplicated there and, moreover, special checks should be added across j.l.i API to reject any inputs which require DVT support. It looks like an overkill from both API & implementation perspective.
>> IMO there's a better alternative: only keep MVT-specific API experimental (VCC->DVT, withers, etc) and enhance j.l.i implementation to support DVT-capable operations. It doesn't require any public API changes and enables safe removal of MVT-specific API. If there's no way for the user to get a DVT class, then there'll be no way to create any DVT-capable method handle.
> Makes sense - I just wanted to make sure we had a way to 'keep the lid' on top of valueness in MHs :-)
FWIW the same type of entanglement will be there for VarHandles too.
More information about the valhalla-dev