Re: [aspectj-users] coverage, decompile, recompile

[Andrew Clement <CLEMAS@xxxxxxxxxx>]

Sorry Nick, I wasn't telling you off :)  I know
this discussion
is now moving onto how to use clover with source but
I still
want to say something about decompilation. (Sorry,
this next bit
is more aspectj-dev'ish than aspectj-users'ish...)

I have now rewritten the generator for the aspectOf()
method 
and it is producing code that even 'dumb' decompilers
can 
understand.  Here is a decompiled aspectOf()
method with my 
compiler patch in:

public static A aspectOf() {
  if (ajc$perSingletonInstance == null)
    throw new NoAspectBoundException("A",ajc$initFailureCause);
  else
    return ajc$perSingletonInstance;
}

I did *not* want to make this change if it damages
runtime 
performance in any way change so I have run all the
performance 
benchmark tests we have - it seems to, on average,
be 1% faster 
with the alternative implementation of aspectOf.  So,
it's not 
slower and maybe the JIT/JVM are recognizing the alternative

bytecode sequence as an easier pattern to optimize.

I'm hoping to integrate this shortly - depending on
how the
rest of the dev team feel about it?  And I'd
also like to see
if it makes a difference to the latest JRockit issue
that
you raised Nick :)

cheers,
Andy.

Nicholas Lesiecki <ndlesiecki@xxxxxxxxx>
Sent by: aspectj-users-admin@xxxxxxxxxxx

28/05/2004 19:59

Please respond to
aspectj-users

To	aspectj-users@xxxxxxxxxxx
cc
Subject	Re: [aspectj-users] coverage, decompile, recompile

My apologies for claiming that decompiling did not
receive attention. I  
was misinformed.

Also, I didn't mean to imply that AspectJ was at fault in  
incompatibility problems. IMHO most decompilers are not nearly as  
sophisticated or well-engineered as AspectJ. I'd place the fault with  
them.

Cheers,
Nick


On May 28, 2004, at 9:14 AM, Andrew Clement wrote:

>
> We are down in the dirty details aren't we .... we fixed a
> number of problems with decompilation in the run up to AspectJ1.2.
 
> AspectJ always generates valid bytecode but certain decompilers
>  (and even JVMs) aren't always compliant with the JVM spec and
they
> don't interpret the bytecode correctly or they make certain assumptions
> when they see certain patterns.  The case below is an example
that
> I believe we have an open bug report on.  The code we are creating
in
> aspectOf() is simply to check there is a valid aspect instance
> around.  The decompiler should have said:
>
>     public static NameChecking aspectOf()
>      {
>          if(ajc$perSingletonInstance == null)
>            throw new NoAspectBoundException(
>              "org_codehaus_wadi_shared_NameChecking",
>              ajc$initFailureCause);
>            return ajc$perSingletonInstance;
>      }
>
> Andy.
>