Re: Re: Re: bootstrap methods in the constant pool

Le 26/08/2010 15:25, [email protected] a écrit :
> Rémi Forax wrote:
>    
>> Le 12/08/2010 08:20, John Rose a écrit :
>>      
>>> I just posted a prototype patch for local BSMs which works on my unit
>>> tests.
>>>
>>>     http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/asm
>>>
>>> There is also an updated "ldc" patch.
>>>
>>> I've put the patches with some good examples here:
>>>
>>>     http://cr.openjdk.java.net/~jrose/pres/asm-jsr292-examples.zip
>>>
>>>        
>> Wow, you're working in August :)
>> I've planned to work on ASM after my holidays, in 10 days.
>>
>> I will create a svn branch with your patches,
>> I will also add the access modifier tagging a defender method.
>> The next step will be to add retro support of these items in the
>> backport :)
>>      
> after looking carefully at these patches and the proposed changes
> to the bytecode format in JSR 292, the design I prefer to support
> this in ASM is the following:
>
> remove visitLdcInsn, replace it with 6 new methods:
>
> - visitCstNumberInsn(Number n)
> - visitCstStringInsn(String s)
>    

I wonder if these two can not be collapsed in one.

> - visitCstClassInsn(String desc) // replaces Type arguments in visitLdcInsn
> - visitCstMethodInsn(String methDesc) // JSR 292
>    

I prefer visitCstMethodTypeInsn(String methodDesc) // JSR292 MethodType

> - visitCstMethodInsn(String owner, String name, String desc, int tag) // JSR 292
>    

and visitCstMethodHandleInsn(int tag, String owner, String name, String 
desc) // JSR292 MethodHandle
Moving the tag as first argument is in my opinion more like other 
methods visit in ASM.

> - visisCstInvokeInsn(String bootstrapOwner, String bootstrapName, String bootstrapDesc, int bootstrapTag, String methName, String methDesc) // JSR 292
>    

???

> add a new method for InvokeDynamic:
>
> - visitMethodInsn(String bootstrapOwner, String bootstrapName, String bootstrapDesc, int bootstrapTag, String methName, String methDesc) // JSR 292
>    

I think I prefer putting bootstrap info after calling info:
visitInvokeDynamicMethodInsn(methName, methDesc, bootstrapTag, 
bootstrapOwner, bootstrapName, bootstrapDesc)

> do not extend Type to include method types (code already using Type expects Type to be a field type, not a method type)
> do not add ConstantPoolVisitor
> do not add Member
>
> I think this is consistent with the original design goals of ASM to only use primitive
> values in visit method arguments (numbers or strings). Of course it breaks backward
> compatibility, but we could reflect that by changing the version number to 4.0.
>
> BTW, I'm still wondering if JSR 292 is quite stable now (the last time I asked the
> answer was yes, but since then new changes were made - bootstrap methods, etc). Also
> the status of the JSR is "inactive" on its web page?
>    

I don't know if the JSR is active or not but I know that the JSR Expert 
Group is active :)

About the stability of the API, there is a vicious circle for ASM:
ASM is quite popular as backend tool for (dynamic) language runtime,
so If we want the JSR292 bytecode changes to be tested we need a version 
of ASM with these changes.
But because runtime developers test the API using ASM, we have feedback 
that require to change
the JSR292 spec which leads to change the ASM API, etc.

The real question is can we have another round-trip. My answer is I hope 
not.
We know that Hotspot, JRockit and J9 VM engineers have started to change 
their
VMs to be compatible with JSR292 spec. So any new changes of the spec 
(at least the bytecode part)
will have a cost that I think we can't afford.

> Eric
>    

Rémi

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws