2 Replies Latest reply on Jun 28, 2004 4:20 PM by Shigeru Chiba

    Javassist byte code rewriting overhead?

    Jean Deruelle Newbie


      I would like to know what is the overhead of javassist compared with BCEL for adding or modifying some bytcode at runtime ?
      Because in BCEL when you add some new bytecode you don't need to recompile while in Javassist it seems that you add some source code so do you need to recompile or the method ading the bytecode do the transformation of the source code passed in argument and so there is no need to recompile ?
      if this is not the case is there some benchmarking of this comparison available somewhere?

      I'm truly sorry if this is a recurrent question or if this is described in the documentation, I didn't mean to waste any time

      Best regards

        • 1. Re: Stateful Aspects needed (use cases)
          Shigeru Chiba Expert

          > and do stuff with it. So really it means that while
          > we would maintain the configuration as is, meaning
          > that we would support the basic read-ahead setting as
          > it is today, it allows for overridding of that
          > property BY THE CLIENT.

          Yes that is cool. So that is a reason to keep state at the proxy level for configuration.

          > today, it is the commit-option field in the cache
          > interceptor but the point is HOW DO WE GET AT THAT
          > INTERCEPTOR in a standardized way.

          How do we get at an interceptor in a standard way? Redeploy it! Modify the .aspect xml file and redeploy it. For JMX we would need an XML editor MBean that wrapped the .aspect xml file. You understanding what i'm saying? The JMX XML Editor MBean would be attached to the .aspect xml file and would have a save button.

          I'm sick of MBean config being non-persistent. Its our last hurdle before becoming a real light-weight component model.

          > then that map has an adapter that retrieves the
          > setters from the interceptors. So that cache
          > interceptor has setCommitOption(). The adapter knows
          > that the interceptors wants the "commitOption" call
          > so when the value changes the adapter that holds the
          > pointer to the interceptor (that adapater is built at
          > deployment time) will call the interceptor with
          > interceptor.setCommitOption(map.get("commit-option");
          I like this adapter idea too. We just need to make sure that everything is layered here. We want the Aspect framework to be lightweight and usable as a library, a JAR file.

          > the mapping of names to method needs to be something
          > dumb like "remove - lowercase everyone and set the
          > values".
          > This way we solve the problem of coding style while
          > retaining the centralized approach to configuration.
          > This is uber powerful. One of the applications of
          > this is if we have a cluster running we can call the
          > configuration on the whole cluster easily.
          > it is good infrastructure.
          > Do we see eye to eye on this one?

          Yes centralized configuration is good. But you should be able to override.

          At Iona we had the idea of configuration scopes. Scopes could inherit off of one another. So if your current scope didn't have a config value defined it looked to the parent for the value.

          We could have configuration scopes for our Aspects.

          Invocation-Config-Scope extends Proxy's-config-scope extends Global-config-Scope.

          So whenever an aspect needs config info it asks the InvocationScope->Proxy's Scope->GlobalScope.

          So a user can modify configuration on different levels. For the duration of the method call, for a specific reference to a object, or globally for all.

          You get what I'm saying?


          • 2. Re: Javassist byte code rewriting overhead?
            Shigeru Chiba Expert

            That's an interesting question. According to
            the developers of ObjectWeb ASM, ASM is
            10 times faster than BCEL and around 10%
            faster than Javassist. I forgot the exact
            numbers, but BCEL seems very slow because
            of their old-fashioned internal architecture.
            ASM is a very small light-weight library for
            modifying bytecode; it does not provide
            source-level abstraction that Javassist does.

            However, the argument above does not mention
            the compilation by Javassist since the other
            libraries do not provide a compiler. In fact, the
            benchmark by ASM people is a very much toy.
            I don't have any numbers with respect to the
            compilation speed by Javassist, but I think the
            overhead is not as big as you expect. But yes,
            I need some experiments for further discussion
            on this topic.