[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Custom JoinPoints

As I understood the original problem, it arose not as the known problem 
with thisJoinPoint holding references for the duration of the join 
point, but as the problem of caching the JoinPoint object for logging after the 
join point completes.  In that case, there's no reason not to just create
a custom type and populate it yourself, pruning as needed, rather than storing
JoinPoint -- except that doing this means you need thisJoinPoint and
prevents optimization during the join point!

I like your idea about the static state, esp. for performance or security
monitoring.  So it seems fair to ask thisJoinPointStaticPart to always return
the same hashcode, so it could work as a key; I'm not sure offhand why we
don't do that now, but I suppose it could be a memory leak of sorts to 
hold on to it.  I assume you could key off the toString() representation,
but that means constructing it each time, no?  Perhaps a small constant key 
could be accessed via the static part.  

The problem I see with user state on either static or instance join points 
is, who decides who gets the magic slot?  It's a recipe for collision when
we should instead be assuming as a default case that advice at a join
point don't know about each other.  An aspect that relies on the magic
slot will fail in the presence of another aspect relying on the magic slot.

By the same token, an aspect that relies on a custom join point to avoid
memory leaks by redacting information potentially interferes with an aspect
expecting full information. Hmm.

I wonder if we should instead get at the root of the problem by supporting 
the notion that if the user sets thisJoinPoint to null (or calls some 
method on JoinPoint) and no other less-precedent advice uses it, it 
will be gc-able.  Indeed, I think JLS 12.6.1 permits us to make the 
reference null after last use, even without the programmer's consent.  
Hopefully, there's no necessary requirement behind making it final;
around advice closures might be an exception.

Lazy join points are good, and ephemeral ones are even better!

Wes

> ------------Original Message------------
> From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
> To: wes@xxxxxxxxxxxxxx, aspectj-users@xxxxxxxxxxx
> Date: Thu, Oct-5-2006 10:07 PM
> Subject: RE: [aspectj-users] Custom JoinPoints
>
> Hi Wes,
> 
> On entry to the join point a custom join point class could summarize 
> the state (e.g., by recording just an object key) without requiring 
> constructing all the members in the join point (e.g., args). If the only 
> reference to something, say an argument, is made shortly after entering a 
> method, then the VM will often optimize and allow collecting that 
> reference. However, holding on to a reference via thisJoinPoint could pin 
> the object for a long time, significantly changing the memory profile. 
> For example:
> 
> void longRunningMethod(Document bigDocument) {
>    Node subset = findSmallSubset(bigDocument);
>    doLongRunningCalculation(subset);
> }
> 
> Here if you have an instance of thisJoinPoint during 
> doLongRunningCalculation it pins bigDocument in memory. If you can store some key for 
> bigDocument per join point, then in after throwing advice you could 
> reference that key without having held it all.
> 
> A use case I've been interested in is per static part state, to allow 
> computing summary data over a join point.
> 
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx 
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Wes
> Sent: Thursday, October 05, 2006 5:36 PM
> To: aspectj-users@xxxxxxxxxxx
> Subject: RE: [aspectj-users] Custom JoinPoints
> 
> I still don't get it.  How does a custom join point class help?
> The canonical use for user state in join points is to communicate 
> between advice on the same join point, but this is just a special
> form of logging.
> 
> Object creation is not expensive.  Detecting large objects is, as is 
> converting them to String.  So there's no real additional cost to
> doing this with your own data structures compared to supporting 
> custom join points.  It's certainly doable; it's not like your
> application is blocked by not having custom join points.
> 
> (Also, a flight recorder is one of the last things I'd want 
> dumping data randomly by using weak references.)
> 
> Wes
> 
> > ------------Original Message------------
> > From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
> > To: aspectj-users@xxxxxxxxxxx
> > Date: Thu, Oct-5-2006 3:37 PM
> > Subject: RE: [aspectj-users] Custom JoinPoints
> >
> > Hi Savita,
> > 
> > It seems to me that being able to manage per join point state could 
> > help with your use case (and it's a feature I too would very much 
> like to 
> > see added). You could store additional related state in the extra 
> state 
> > of a join point object as you could in a custom extension of join 
> > point, and the overhead ought to be similar (maybe with one more 
> object 
> > being allocated by the AspectJ runtime).
> > 
> > The interesting wrinkle in your case is the desire to avoid pinning 
> > large objects in memory. For that you'd really like the ability to 
> store 
> > state per join point but *not* pin the join point object. If the per 
> > join point storage facility were separate from the join point, that 
> would 
> > allow computing small objects without holding references to 
> potentially 
> > large data structures. I don't think this would be valuable for per 
> > static part storage, because there the data being held is a small 
> constant 
> > and has been made quite small.
> > 
> > I think the next step is really for someone to create a good design 
> and 
> > implementation. I don't know what the committers plans are in this 
> > respect, but am eager to know.
> > 
> > My $.02,
> > Ron
> > 
> > 
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx 
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, 
> Savita
> > Sent: Thursday, October 05, 2006 11:22 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: RE: [aspectj-users] Custom JoinPoints
> > 
> > Hi Ron,
> > 
> > Iam curious to know what the Inquiring minds thought about the use 
> case 
> > below. and if we plan to do something about it?
> > 
> > Thanks,
> > Savita
> > 
> > -----Original Message-----
> > From: "Chandan, Savita" <Savita.Chandan@xxxxxxxxxxxxxx> 
> > Date: Fri, 29 Sep 2006 17:56:48 -0700 
> > Delivered-to: aspectj-users@xxxxxxxxxxx 
> > Thread-index: Acbisvt1A3npu+aVRN2g6xviHMHe3wAFRhnAAEfALYAAEDbSYA== 
> > Thread-topic: [aspectj-users] Custom JoinPoints 
> > 
> > 
> --------------------------------------------------------------------------------
> > 
> >  
> > I was intending to do more research before I responded to any of the
> > other emails, but haven't had a chance to do that.
> > 
> > Anyways, My requirement was,
> > 
> > If I could have a custom JoinPoint that can do special translation 
> for
> > some specific method arguments in its current context.
> > 
> > The reason being, In a FlightRecorder utility, if I were to cache the
> > JoinPoint for dumping the data to a log file at a later time and one 
> of
> > the method arguments had a huge memory footprint, I wouldn't want to
> > cache that particular argument and hold on to the reference, instead 
> I
> > would convert that parameter to a brief String in the JoinPoint and
> > cache the JoinPoint. My Custom JoinPoint would detect such arguments 
> > and
> > immediately convert them to a brief string and not cache the object
> > argument ( Not sure what can of worms that this would open, but it
> > should be doable right?)
> > 
> > Now, may be there are other ways of doing this without derived/Custom
> > JoinPoint, like the user object proposed in the bug for AspectJ
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=89009. This would mean
> > creation of 2 objects for logging ( one is the JoinPoint that would 
> be
> > created and other is the userObject to be set in the JoinPoint in
> > addition to some reflection calls). I think the hit would be limited 
> to
> > creation of just 1 Object if the userObject was part of 
> StaticJoinPoint
> > ( which was also suggested in the bug comments).
> > Or 
> > another idea that was brought up independent of AspectJ was using 
> weak
> > references which again is Object creation ( might end up doing this 
> if
> > nothing else works).
> > 
> > Hope this discourse above is clear enough to explain my requirements.
> > 
> > Savita
> > 
> >  
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> > Sent: Friday, September 29, 2006 10:42 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: RE: [aspectj-users] Custom JoinPoints
> > 
> > So Savita,
> > 
> > Inquiring minds want to know: what behavioral modification of a join
> > point
> > are you seeking to achieve?
> > 
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx 
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Wes
> > Sent: Thursday, October 05, 2006 11:03 AM
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: Re: [aspectj-users] Warning return
> > 
> > IDE support for messages is basically to mark them as warning or 
> error, 
> > so we already
> > provide all the information that IDE's currently support.  Indeed, 
> AJDT 
> > goes to the 
> > trouble of providing dual links, one to the code making the violation 
> 
> > and one to 
> > the code defining violation.  (For discussions of extending AOP IDE's 
> 
> > to do new
> > and cool things, see adjt-dev@xxxxxxxxxxxx)
> > 
> > It's not clear to me that what you're suggesting would work with all 
> > IDE's or all 
> > implementations of AspectJ.  I recommend submitting a bug that 
> > specifies a use-case
> > (what you want and how it will help), and optionally proposing an 
> > implementation.
> > I'm not aware of any other compiler that executes user-defined code; 
> > take that 
> > into consideration when considering the implementation.
> > 
> > I suggested specially-coded warning strings and a custom message 
> > handler in order 
> > to give you a way to prototype the kinds of warnings and analysis 
> you'd 
> > like to 
> > provide using pointcuts.  It's really an implementation detail 
> whether 
> > we use
> > 
> >   "9 Something bad is coded here"
> > 
> > or 
> > 
> >   new WarningMessage(9, "Something bad is coded here")
> > 
> > since you can define your message handler to produce such 
> > WarningMessage and
> > consume them yourself.  I agree that it's not the best for most 
> > programmers,
> > but it should give you a way to build up the kind of analysis you 
> want.
> > 
> > In any case, there is a high bar for changing the AspectJ language, 
> > even
> > in a backwards-compatible way, so the use case should be compelling.  
> 
> > For that,
> > it would be good to see the kinds of warnings, etc. you propose.  As 
> I 
> > said,
> > I personally believe that the set of things you can find by analyzing 
> 
> > code for errors 
> > on a per-join-point basis is far outstripped by what other tools do 
> by 
> > evaluating the 
> > structure of code (i.e., whole-program analysis).  Thus, I believe 
> any 
> > general-
> > purpose application would not be compelling because better 
> alternatives 
> > exist.
> > 
> > However, it's very compelling to have aspect-related declarations 
> that 
> > prove
> > assumptions being made by pointcuts and to make simple per-join-point 
> 
> > assertions
> > about illegal practices. That's what we do already.
> > 
> > This is one of the most interesting application areas, so if you can 
> > propose
> > something interesting in the bug, that would be great. 
> > 
> > hth - Wes
> > 
> > > ------------Original Message------------
> > > From: "matsui akira" <akira_in_tokyo@xxxxxxxxxxx>
> > > To: aspectj-users@xxxxxxxxxxx
> > > Date: Thu, Oct-5-2006 6:17 AM
> > > Subject: [aspectj-users] Warning return
> > >
> > > Sorry for insisting on this topic. I really believe this is 
> something 
> > 
> > > we 
> > > could take a look at more carefully. Since the subject deviated 
> since 
> > 
> > > the 
> > > original message, I think it is best to start a new conversation.
> > > 
> > > I believe warnings give to IDE a good oportunity to improve code 
> > > measurement and interaction with programmer.
> > > 
> > > I have seen strings-based programming failing many times. So my 
> > > suggestion 
> > > is to change the return type to Object or a new interface. So 
> warning 
> > 
> > > declaration could be both:
> > > 
> > > declare warning : bad() : new WarningMessage(9, "Something bad is 
> > coded 
> > > 
> > > here.");
> > > 
> > > or
> > > 
> > > declare warning : bad() : "Something bad is coded here.";
> > > 
> > > Message handlers could then do reflection to find from which class 
> > the 
> > > message return is. A simple message handler could simply call 
> > > .toString() 
> > > to print results as current implementation does.
> > > 
> > > This feature can, for example, create reports to measure how many 
> > > directs 
> > > calls exist to file IO within all classes.
> > > 
> > > Also, it would be possible to report how many calls to deprecated 
> > > methods 
> > > exist inside the code. So one could get a legacy code and, in face 
> of 
> > a 
> > > new 
> > > release of libs and without much effort, create an aspect that can 
> > > measure 
> > > its quality.
> > > 
> > > 
> > > >From: "Wes Isberg" <wes@xxxxxxxxxxxxxx>
> > > >Reply-To: aspectj-users@xxxxxxxxxxx
> > > >To: aspectj-users@xxxxxxxxxxx
> > > >Subject: Re: [aspectj-users] Describing the chattyness
> > > >Date: Sat, 30 Sep 2006 12:38:49 -0700
> > > >
> > > >This is an interesting problem area but one not directly in
> > > >the domain of AOP.
> > > >
> > > >While declare error/warning can pick out specific
> > > >staticly-determinable join point, pointcut languages aren't
> > > >typically set up to make assertions across join points or
> > > >about missing join points (e.g., you should implement this
> > > >method or have a constructor that takes this argument), so
> > > >things like JQuery are better suited to that.  However,
> > > >those are often limited to static analysis, and the runtime
> > > >capabilities of AOP can augment those systems.  For
> > > >example, it's a common aspect to track a use pattern like
> > > >(open stream, use stream, close stream) where the stream
> > > >might be opened, used, and closed by different components.
> > > >  AOP is good at detecting that the stream was not closed
> > > >and who was supposed to.
> > > >
> > > >
> > > >On the question of the warning level, the user can encode a
> > > >particular level in the message, e.g.,
> > > >
> > > >   declare warning : bad() : "09 bad thing";
> > > >
> > > >Not the best, but...
> > > >
> > > >Also, the message handlers are pluggable so you can set up
> > > >programmer support at build time by installing a message
> > > >handler that does something special when given your special
> > > >messages (e.g., counting up an overall "score" for a
> > > >program given all the messages).
> > > >
> > > >hth - Wes
> > > >
> > > >On Sat, 30 Sep 2006 20:36:59 +0900
> > > >  "matsui akira" <akira_in_tokyo@xxxxxxxxxxx> wrote:
> > > > > I believe this use points to an interesting application
> > > > > for AOP. Warnings could be used to measure code. In this
> > > > > case, the number of communication with a certain layer
> > > > > could be counted by a tool that attaches to the IDE in
> > > > > use and give the programmer a quantification about the
> > > > > code.
> > > > >
> > > > > I already had a similar problem before. I had to create
> > > > > advices to tell programmers about choices that could
> > > > > reflect in bad execution performance. Programmers could
> > > > > have a tool that give them an overal report about code
> > > > > quality so that this could guide their development.
> > > > > Warnings could be classified according to it severity.
> > > > >
> > > > > As a sugestion, warning declaration could be changed
> > > > > optionally to the following:
> > > > >
> > > > > declare warning (10, WARNING_CLASS) : within({Business});
> > > > >
> > > > > where 10 is the severity and WARNING_CLASS is an
> > > > > enumeration item.
> > > > >
> > > > > >From: "Wes" <wes@xxxxxxxxxxxxxx>
> > > > > >Reply-To: wes@xxxxxxxxxxxxxx, aspectj-users@xxxxxxxxxxx
> > > > > >To: aspectj-users@xxxxxxxxxxx
> > > > > >Subject: Re: [aspectj-users] Describing the chattyness
> > > > > >Date: Thu, 28 Sep 2006 10:57:59 -0700
> > > > > >
> > > > > >
> > > > > >Calls from Business:
> > > > > >
> > > > > >   declare warning : within({Business}) && call({Dao}) :
> > > > > "business ->
> > > > > DAO";
> > > > > >   where {Business} and {Dao} depend on your system.
> > > > > >
> > > > > >Similarly, callbacks from DAO:
> > > > > >
> > > > > >   declare warning : within({Dao}) && call({Business}) :
> > > > > "DAO ->
> > > > > Business";
> > > > > >
> > > > > >For a runtime accounting, use advice to log the same
> > > > > pointcuts.
> > > > > >
> > > > > >Is that what you were looking for? ("reference count"
> > > > > typically means
> > > > > >the number of references to a particular object.)
> > > > > >
> > > > > >(See also JDepends.)
> > > > > >
> > > > > >Wes
> > > > > >
> > > > > >btw, search didn't turn up any relevant definition of
> > > > > "AMOF"
> > > > > >
> > > > > > > ------------Original Message------------
> > > > > > > From: Thomas SMETS - disposable add
> > > > > <duvelbier-tsmets@xxxxxxxxx>
> > > > > > > To: aspectj-users@xxxxxxxxxxx
> > > > > > > Date: Thu, Sep-28-2006 10:50 AM
> > > > > > > Subject: [aspectj-users] Describing the chattyness
> > > > > > >
> > > > > > >
> > > > > > > Dear,
> > > > > > >
> > > > > > > I was wondering how I could do a reference count...
> > > > > > > AMOF, I would like to measure the level of chattyness
> > > > > in my code :
> > > > > > >
> > > > > > >
> > > > > > >         Service Layer <--> Business Layer <--> Dao
> > > > > <--> DB
> > > > > > >
> > > > > > >
> > > > > > > If I can forbid the Service to talk directly to the
> > > > > Dao, I woundered if
> > > > > > > I could also point the places where the Business was
> > > > > chatting too much
> > > > > > > with the DAO's (hence the DB).
> > > > > > >
> > > > > > > Any hint into this would be appreciated !
> > > > > > >
> > > > > > > \T,
> > > > > > >
> > > > > > >
> > > > > > > --  Any fool can write code that a computer can
> > > > > understand.
> > > > > > > Good programmers write code that humans can
> > > > > understand.
> > > > > > >
> > > > > > > Martin Fowler
> > > > > > >
> > > > > > > T. : +32 (0)2 742 05 94
> > > > > > > M. : +32 (0)497 44 68 12
> > > > > > > @  : duvelbier-tsmets@xxxxxxxxx
> > > > > > > Do you skype too ... (tsmets) ?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > aspectj-users mailing list
> > > > > > > aspectj-users@xxxxxxxxxxx
> > > > > > >
> > > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > > > >
> > > > > >
> > > > > >_______________________________________________
> > > > > >aspectj-users mailing list
> > > > > >aspectj-users@xxxxxxxxxxx
> > > > > >https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > >
> > > > >
> > > >_________________________________________________________________
> > > > > ããããPCãååçæãçæããããããçæããã 
> > > http://safety.live.com/
> > > > > _______________________________________________
> > > > > aspectj-users mailing list
> > > > > aspectj-users@xxxxxxxxxxx
> > > > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > >
> > > >_______________________________________________
> > > >aspectj-users mailing list
> > > >aspectj-users@xxxxxxxxxxx
> > > >https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > 
> > > _________________________________________________________________
> > > auçãããããããEZãããæçåïããããçæããããããï 
> > > http://promotion.live.jp/messenger/mobile.htm 
> > > 
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > 
> > 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>