Use of JDK interanl ASM vs external

[Remi Forax]

On 02/18/2015 11:30 PM, Attila Szegedi wrote:
> With Nashorn, we're language implementers who happen to have their 
> runtime shipped as part of the JRE. For better or worse, we need to 
> have our dependencies shipped with it, hence a privately bundled ASM. 
> We have a somewhat unique deployment model, if you wish. It is still 
> OW2 Consortium's ASM, so we don't get any toys that you wouldn't get 
> if you included a copy of ASM with your runtime. I saw Remi mentioning 
> that the bundled ASM supposedly has some methods elevated to public 
> level, but I honestly am not aware of that in my usage of it.

no, lambda forms implementation use one internal method but there is a 
simple way to use the public API to do the same thing,
it's really a detail, I should not have mention it.

> So, I'm not really aware of any toys we keep for ourselves. I've been 
> talking about "dynamic bytecode toolkit" at various conferences, but 
> that's work I want to tackle in the future, we don't have that yet, 
> unfortunately (I'd be thrilled if I woke up and it was there, 'cause 
> it'd mean I wrote it in my sleep :-) )
>
> Attila.

BTW, I've just written a new 'dynamic bytecode toolkit' on top of ASM,
   https://github.com/forax/vmboiler
that should help everybody that what to do type specialization on top of 
the VM.

once JDK-8072008 [1] will be fixed, perf for primitive ops will be not 
far from Java
(I consider that perf for reference ops are already on par).

Rémi
[1] https://bugs.openjdk.java.net/browse/JDK-8072008

>
> On Feb 18, 2015, at 10:34 PM, Mark Roos <mroos at roos.com 
> <mailto:mroos at roos.com>> wrote:
>
>> A statement from Remi defined the reason for my original question 
>> very well.
>>
>>         the ASM packages are only
>>        re-exported [1] for nashorn
>>
>> Like the Nashorn folks I am building a language using the jvm for 
>> which it  would
>> be helpful if there was a standard api for bytecode writing.  One 
>> which kept up
>> with the movement of the jvm and was focused on the needs of language 
>> writers. I
>> am jealous that these folks get toys that I only hear talks on.
>>
>> While I understand the desire to hide the internals of Java from the 
>> users of the
>> language, my preference would be for a way to open these internals 
>> for those of
>> us more interested in targeting the jvm.  Perhaps similar to how 
>> Nashorn has
>> the exports enabled.
>>
>> regards
>> mark
>>
>> p.s.   Nice usage of Star Wars quote :)
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net <mailto:mlvm-dev at openjdk.java.net>
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150219/c0e35bd2/attachment.html>