Question about get Method Handle to interface field

[Radek Smogura]

Hi all,

I’m really sorry but my message has bounced from SMTP again.

I think that’s this change looks ok for me right now. I will try to invent something simpler.

@Remi,

Actually I’m not on properties I can go back to it if someone would be interested in syntax like public property int x or public property int y {get {}, set{}), I think I stopped on porting to JDK9, but still I should have a full patch, form “early, non-module" JDK9.

This what I’m on is java.expression:

https://bitbucket.org/radoslaw_smogura/panama-langtools/branch/javax.expression-v2

It’s an expression API to capture and give AST of Java structures, like jinq, but giving more predictable results. Right now I’m focusing on lambda, however as lambda can declare arbitrary structure I think there is no need to limit this to lambdas.

Purpose of this package is to allow transformation of Java to something else, one my build SQL, I like CUDA.

I’ve used following approach: during compilation I build tagged tree: each tree, depending on type and shape, gets tag. The tagged tree is stored as a String in class (I have version which keeps it externally alongside with .class file). String is pretty good as long each tag would not exceed 7 bits (who said strings should be readable?).

When lambda is created I pass this tree as new parameter to metafactory.

To minimise size of this tree (which is compared to size of byte code), I wanted to use constant pool. However as there is no API to access it right now, I’m using “virtual” pool. I pass constant references as var args to lambda metafactory. Constants and classes are passed as is, methods as handles, and fields as handles to get field (this is why I’ve found this bug).

Metafactory associates those values with Lambda implementation class. It’s not optimal right now, and has some limitations, mainly due to lack of mentioned access to true constant pool.

On runtime one can use ExpressionIntrospector to extract AST together with meta information (like captured variables) in the form of nice looking Expression tree. ExpressionIntrospector builds tree on demand. I’ve built API in such a way that after transformation, tree can be disposed, and only few very lightweight objects has to be kept to support execution of transformed AST (as long as someone would use good practice to parametrize transformed code with captured variables).

There are still few things I’m thinking about, one is to integrate with Java model package, or reusing similar technique to reify generics.

Bit out of scope, but right now I use above package to build runnable CUDA kernels, and have a lot fun allowing constructs like this:

    int[] data = (int[]) (Object) (((Long) (Object) dataArray) + dataChunkBegin * 4);

But it’s version for hardcores only ;)

- https://bitbucket.org/radoslaw_smogura/panama-langtools/branch/javax.expression-v2 (core changes)
- https://bitbucket.org/radoslaw_smogura/panama-jdk/branch/javax.expression-v2 (idk changes)
- https://bitbucket.org/radoslaw_smogura/panama-build/branch/javax.expression-v2 (top-level tree)
- https://github.com/rsmogura/cuda-java-samples (CUDA sample)

Kind regards,
Radek

> On 5 Sep 2017, at 01:25, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 
> On 02/09/17 20:26, Remi Forax wrote:
>> Hi Radek,
>> Do you still trying to implement properties in Java ?
>> 
>> It seem to be an overlook to me,
>> getstatic and putstatic are allowed on a static field declared in an interface, getstatic and putstatic use a CONSTANT_Fieldref so unlike constant method handle based on method which need to know if the owner is an interface or not (to generate a CONSTANT_Methodref or a CONSTANT_InterfaceMethodRef), see JVMS 4.4.2.
>> 
>> The following patch should fix the issue
>>   case ClassFile.REF_getStatic:
>>   case ClassFile.REF_putStatic:
>>       staticOk = true;
>> +       interfaceOwner = true;
>>   case ClassFile.REF_getField:
>> 
>> Rémi
> That's right - that code is buggy and does not handle field handles correctly, mostly because does not need them. Anyway, if you come up with a patch which works for your use case, I'd be happy to take a look. What Remi suggests seems sensible, although I have a feeling that this logic could be simplified a little.
> 
> Maurizio
>> 
>> ----- Mail original -----
>>> De: "Radek Smogura" <rsmogura at gmail.com>
>>> À: compiler-dev at openjdk.java.net
>>> Envoyé: Samedi 2 Septembre 2017 19:20:06
>>> Objet: Question about get Method Handle to interface field
>>> Hi all,
>>> 
>>> Recently I played a little bit and tried to obtain MethodHandle to GET method
>>> for interface static field. The code which I try to use is
>>> 
>>> new Pool.MethodHandle(ClassFile.REF_getStatic, sym, types);
>>> 
>>> But it fails on assertion: Assert.check(!refSym.owner.isInterface() ||
>>> interfaceOwner) located in MethodHandle.checkConsistent:365 ?
>>> 
>>> I wonder if such handles are allowed?
>>> 
>>> Thanks,
>>> Radek
>>> 
>>> P.S. Sorry if I post this message twice, but I got SMTP issues