[jboss-dev] Further profling: Where should I focus?

[Bill Burke]

Ales Justin wrote:
>> IMO, we should just remove AOP entirely as our customers probably are
>>  not going to use it. 
> 
> This is exactly what will happen - remove AOP - if we disable it by 
> default and re-write lifecycle handling to plain OO, w/o any costly 
> pointcut matching.
> 
> The only cost is lookup for potential @AOPEnable on the bean.
> While we still keep optional cool feature of creating an AOP proxy for a 
> bean.
> 
>> For @JMX just write another deployer and do it
>>  regularly.  Similarly with lifecycle and other features.
> 
> Regularly?
> If you mean to register an mbean, that is actually not what we/users want.
> See my response to Dimitris this morning.
> 

There probably is a way to make AOP irrelevant to boot performance, but 
you need to consider pluses and minuses nevertheless...Everybody 
(thousands) of users are effected by boot performance, while only a 
handful care about @JMX, etc.

> While this could be a deployer feature, I think it's far more complex to 
> do it than tie it into the bean's lifecycle.
> e.g. scan for @JMX, remembering the handle, checking if it's overridden 
> for an instance, ... while we already have all this implemented in 
> bean's lifecycle handling, it's just not optimized yet.
> 
> What do you mean by "similarly with lifecycle and other features"?
> @JMX, @JNDI, @Password, ... is the lifecycle callback.
> 

All these annotations that trigger AOP.  Are they under the jboss 
namespace?  Controlled by us?

You might want to consider meta-annotations and turning @AOPEnabled into 
one. i.e.

@AOPEnabled
public @interface JMX {...}

You look at the bean's class annotations, then look at those annotations 
for @AOPEnabled.

>> Again, if you want to take this route, I'd be happy to do the work.
>> I am willing to spend the next month on boot performance and AS.
> 
> Excellent.
> So will I and the rest of MC team.

Well, I need to know what I could do to help.  Is Kabir fine on the AOP 
stuff?  VFS3 seems to be ok?  What about removing JMX Kernel Backward 
Compatibility and upgrading services to MC?  I can tackle any of these 
problems with little guidance I just don't want to be duplicating any 
work (like with the deployer sorting).

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com