On 10/20/2014 11:25 AM, Cédric Champeau wrote:
For what it's worth, in Groovy, we have two separate pathes to "implement classes at runtime", that is to say generating proxies. In the case of an interface, we rely on the JDK proxy just because it is *much* faster than generating a class through ASM. I mean that generating a class in ASM is orders of magnitude slower (at least in our case) than relying on the JDK proxy adapters. Of course, it then depends on how often the method is called, because at some point a generated class will be faster, but so far, the choice we made is better in practice, because lots of people do not realize that if they do "foo as SomeInterface" in a loop, they are generating a new proxy for each call...

I've just taken a look to the code of j.l.r.Proxy, (sun.misc.ProxyGenerator), and I don't understand how ASM can be an order of magnitude slower, if you just look to how the code is generated. So I suppose that it's because j.l.r.Proxy use it's own defineClass() method instead of the one in ClassLoader, and that this defineClass() avoid to spend time to do things like class verification.

Rémi


2014-10-20 11:19 GMT+02:00 Paul Sandoz <paul.san...@oracle.com <mailto:paul.san...@oracle.com>>:


    On Oct 18, 2014, at 6:59 PM, Peter Levart <peter.lev...@gmail.com
    <mailto:peter.lev...@gmail.com>> wrote:
    >
    > Hi Paul, Remi,
    >
    > The complete solution will require new API, but the
    java.lang.reflect.Proxy API could be improved a bit too. With
    introduction of default interface methods it is somehow broken
    now. Default interface methods enable interface evolution, but
    break existing Proxy InvocationHandler(s) which are not prepared
    to handle new methods. So perhaps a small improvement to Proxz API
    could be to add new factory method that takes an additional a
    boolean flag indicating whether generated proxy should override
    default methods and forward their invocation to InvocationHandler
    or not. An all-or-nothing approach. I know that even that is not
    trivial. Generated proxy class can implement multiple interfaces
    and there can be conflicts. In that case, the easiest solution is
    to bail out and refuse to generate a proxy class with such
    combination of interfaces.

    It would also be useful to investigate a safe mechanism so that an
    InvocationHandler implementation can call a default method, which
    then allows an impl to explicitly deal with conflicts.


    >
    > A starting point could be to re-implement current functionality
    using ASM and then start experimenting with different approaches.
    What do you think?
    >

    Not sure replacing the bytecode generating implementation, in
    sun.misc.ProxyGenerator, with an ASM equivalent will really help
    all that much functionality wise, that may be nice from a
    unification perspective but does introduce some risk. A quicker
    route might be to work out how to filter out the default methods
    that are overridden in the existing code.

    Paul.

    _______________________________________________
    mlvm-dev mailing list
    mlvm-dev@openjdk.java.net <mailto: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

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to