Re: hg: mlvm/mlvm/jdk: meth-lazy: moved to ASM for bytecode generation
On 05/02/2012 02:37 AM, Christian Thalinger wrote:
> On May 1, 2012, at 2:38 PM, Rémi Forax wrote:
>
>> On 05/01/2012 09:24 PM, christian.thalin...@oracle.com wrote:
>>> Changeset: 5ec0f6472b4b
>>> Author:twisti
>>> Date: 2012-05-01 12:24 -0700
>>> URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/5ec0f6472b4b
>>>
>>> meth-lazy: moved to ASM for bytecode generation
>>>
>>> ! meth-lazy-7023639.patch
>>>
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> Hi Christian,
>> in emitIconstInsn, you forget ICONST_M1, also
> We don't need M1 :-)
>
>> ICONST_M1, ICONST_0, ICONST_1, etc are subsequent values so
>> you can write:
>> switch(i) {
>> case -1:
>> case 0:
>> case 1:
>> case 2:
>> case 3:
>> case 4:
>> case 5:
>>opcode = Opcodes.ICONST_0 + i;
>> ...
>> }
> I could do that, right.
>
>> for emitLoadInsn, emitStoreInsn and emitReturnType, you can use
>> the same switch that map 'I', 'J', 'F', 'D', 'A', 'V' to 0...5,
>> because ISTORE, ILOAD and IRETURN variants are all in the same order.
>>
>> Also nextEIID and nextNFID can use an AtomicInter and its method
>> getAndIncrement
>> instead of a synchronized method, it should be more efficient.
> These were supposed to be debugging only since the anonymous class loader
> defines each class uniquely anyway. Not sure if we keep them or not.
Yes, right.
>
> -- Chris
Rémi
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: hg: mlvm/mlvm/jdk: meth-lazy: moved to ASM for bytecode generation
On May 1, 2012, at 2:38 PM, Rémi Forax wrote:
> On 05/01/2012 09:24 PM, christian.thalin...@oracle.com wrote:
>> Changeset: 5ec0f6472b4b
>> Author:twisti
>> Date: 2012-05-01 12:24 -0700
>> URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/5ec0f6472b4b
>>
>> meth-lazy: moved to ASM for bytecode generation
>>
>> ! meth-lazy-7023639.patch
>>
>> ___
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> Hi Christian,
> in emitIconstInsn, you forget ICONST_M1, also
We don't need M1 :-)
> ICONST_M1, ICONST_0, ICONST_1, etc are subsequent values so
> you can write:
> switch(i) {
> case -1:
> case 0:
> case 1:
> case 2:
> case 3:
> case 4:
> case 5:
> opcode = Opcodes.ICONST_0 + i;
> ...
> }
I could do that, right.
>
> for emitLoadInsn, emitStoreInsn and emitReturnType, you can use
> the same switch that map 'I', 'J', 'F', 'D', 'A', 'V' to 0...5,
> because ISTORE, ILOAD and IRETURN variants are all in the same order.
>
> Also nextEIID and nextNFID can use an AtomicInter and its method
> getAndIncrement
> instead of a synchronized method, it should be more efficient.
These were supposed to be debugging only since the anonymous class loader
defines each class uniquely anyway. Not sure if we keep them or not.
-- Chris
>
> cheers,
> Rémi
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: hg: mlvm/mlvm/jdk: meth-lazy: moved to ASM for bytecode generation
On 05/01/2012 09:24 PM, christian.thalin...@oracle.com wrote:
> Changeset: 5ec0f6472b4b
> Author:twisti
> Date: 2012-05-01 12:24 -0700
> URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/5ec0f6472b4b
>
> meth-lazy: moved to ASM for bytecode generation
>
> ! meth-lazy-7023639.patch
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Hi Christian,
in emitIconstInsn, you forget ICONST_M1, also
ICONST_M1, ICONST_0, ICONST_1, etc are subsequent values so
you can write:
switch(i) {
case -1:
case 0:
case 1:
case 2:
case 3:
case 4:
case 5:
opcode = Opcodes.ICONST_0 + i;
...
}
for emitLoadInsn, emitStoreInsn and emitReturnType, you can use
the same switch that map 'I', 'J', 'F', 'D', 'A', 'V' to 0...5,
because ISTORE, ILOAD and IRETURN variants are all in the same order.
Also nextEIID and nextNFID can use an AtomicInter and its method
getAndIncrement
instead of a synchronized method, it should be more efficient.
cheers,
Rémi
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
