RFR: 8238549: Add explicit cast to correct implementation type in VarHandle implementation methods

[Maurizio Cimadamore]

On Thu, 6 Feb 2020 01:18:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Hi,
> as promised, I took a look into adding a bit more structure under our var handle implementations - more specifically, I've tweaked the signatures of the various implementation methods to take a plain VarHandle instead of a var handle implementation class.
> 
> This was tedious, but ultimately easy to do. Since, to do this in a complete way I also had to touch regular var handles (e.g. non-memory access ones), it seemed like a good idea to take an existing var handle test (VarHandleTestMethodTypeXYZ) and tweak it so that it tests all combinations of (adpated=yes/no, guards=yes/no). This revealed several issues in the adapter logic:
> 
> * first, varType() and coordinates() triggered a resolution of some of the underlying MH attached to the indirect handle - since this can fail with UOE, these methods could also fail spuriously with UOE which is wrong
> 
> * second, accessModeTypeUncached, in addition to the aforementioned problem, also had an issue in that it didn't make correct use of the direct handle target
> 
> * third, I realized that I did not update the lambda forms for var handle invokers to also call VarHandle::asDirect - this was causing issues when calling an adapted handle through the invoker
> 
> With these changes, all tests pass despite the extra layers of adaptation. So, in the end it turned out to be a fruitful bug hunt (thanks for the hint Paul!).
> 
> Cheers
> Maurizio

I've uploaded another revision which removes a redundant cast in AddressVarHandleGenerator. I also tried to tweak all casts to use the implementation class, rather than BASE_CLASS, but that doesn't work - probably an issue with anonymous classes when resolving a superclass field from an anon instance (subclass).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/6