[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] poss optimisations for target() when can't weave
|
[I'd reply inline if I weren't using Outlook which just
won't do internet style.]
Bloat. Yes, understand in the case of
execution(), but where the user is forced to use call because the target cannot
be woven, then it'd reduce code bloat and help JIT. Seems to me that
minimising the use of call() helps build times, and LTW
times.
I'll stick an enhancement
request in later (at least others might find it and comment too), and maybe even
have a look at prototyping it. It could be that I'm on a particularly
weird project that has this use case show up, so it's definitely not high
priority.
Once I get some time in late April, I may get a chance
to capture what has and hasn't worked on this project - even if it's extended, I
expect to free up a day a week for open source efforts.
Hi Neale,
2009/3/26 Neale Upstone
<neale.upstone@xxxxxxxxxx>
Would
this not be a useful approach?
Could be... show me there is a performance problem with the generated
code we have today or a (real) use case that it doesn't work for and I would
investigate - I don't like optimizing without good cause. I've enough
work to do on bugs we do have :)
It would
save the runtime check and allow the advice to be applied with the least
weaving / code bloat, and therefore would help
performance.
Adding a new method to the subtype is code bloat...
I
suspect it may be a special case, and that what you're doing at the moment
allows the rest of the pointcut to be quite general. e.g. &&
((target(X) || target(Y)) would require code inserting in multiple
places. I still suspect it's better than grabbing every call() in the
case where the target joinpoint is within a lib we don't want to
weave.
It's
also worth considering how this applies in the world of Equinox
Aspects. Doing the least weaving and having flexibility as to where
that weaving happens could be quite
important.
I do prefer general purpose reusable solutions for weaving - I tend
to only look to special case for something that really needs it (for
performance or feasibility reasons). The JIT can do a better job in many
cases than I can by crafting some intricate bit of code - so I will only
meddle with optimization of generated code if necessary. We have no open
bugs related to the performance of the generated code (though there may well
be issues but no-one is telling me about them...). If you have a real
use case then please raise an enhancement request so it isn't lost in the
mailing list traffic. You may be onto something with the flexibility
equinox aspects will need given classloader boundaries and what the weaver can
get to (although if every bundle has a weaver attached to its classloader, we
can weave anywhere).
Andy.
We don't insert any methods like that. It will advise the
setVisible method in the superclass with a runtime check to see what
'this' is at the time setVisible is running - if it is a MyForm then the
advice will run.
Andy.
2009/3/25 Neale Upstone
<neale.upstone@xxxxxxxxxx>
This
reminds me of a question I meant to ask.
If I create around()
advice for a method that is not implemented in the
target class, and
the implementation does exist in the super class,
what
happens.
I know that call(public void
setVisible(boolean)) && target(MyForm) will
weave at the call
sites, but... what does the weaver do with:
execution(public void setVisible(boolean)) && this(MyForm)
?
I'd hope that it ends up with a method added to MyForm,
where proceed()
calls super.setVisible().
Is that the
case?
**********************************************************************
IMPORTANT NOTICE.
Confidentiality: This e-mail and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this e-mail and highlight the error.
Security Warning: Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium.
We advise that you understand and observe this lack of security when e-mailing us.
Viruses: Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Monitoring and Scanning: Cambridge Cognition has monitoring and scanning systems in place in relation to emails sent and received to: monitor / record business communications; prevent and detect crime; investigate the use of the Company's internal and external email system; and provide evidence of compliance with business practices.
Cambridge Cognition Limited
Company Registration Number 4338746
Registered address:
Tunbridge Court
Tunbridge Lane
Bottisham
Cambridge
CB25 9TU
UK
**********************************************************************
