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

Hi Savita,

Your approach to buffering the join point normally makes sense to me. Even
if you did decide to log a custom data structure you probably would still
benefit a lot from using AspectJ.

If you want to trim join point state, I'd start by prototyping with a
separate object that holds the state you care about, then look at how to
optimize further. If you are constructing join points eagerly anyhow, then I
think the normal constructor would be fine:

public JoinPointImpl(org.aspectj.lang.JoinPoint.StaticPart staticPart,
Object _this, Object target, Object[] args) {
...
}

You could just store the state you cared about from that. See
http://dev.eclipse.org/viewcvs/index.cgi/org.aspectj/modules/runtime/src/org
/aspectj/runtime/reflect/JoinPointImpl.java?rev=HEAD&cvsroot=Tools_Project&c
ontent-type=text/vnd.viewcvs-markup for the JoinPointImpl class...

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
Sent: Friday, October 06, 2006 5:27 PM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Custom JoinPoints

Ron,

For smaller data structures and trace logevents,  I was planning on just
buffering the Join Point itself instead of a custom data object.
The reasoning was that if we are already taking a hit with creation of
Joinpoints which has all the information why replicate it by translating
it to custom object. These JoinPoints would exist till the logbuffer
wraps around dropping the older log events. 
The option of converting the data to be logged to a custom data struct
was thought of and is in our list of options, if we didn't use AspectJ. 
Again, during the design phase, I am sure we will think about it more
and come with some more options ( or tradeoffs) this will not gate us,
My whole reasoning for this exercise was to understand how far we can go
with the AspectJ framework. 

As for what you describe for what is required of a custom join point,
you are right that just sub classing in itself doesn't do it, but
something more is required. Looks like trimming the Join Point State is
not very simple ( Iam not familiar with the internals of the Join Point
state management implementation.) Is there any good documentation on
this? Or do I need to delve into the source code to see how this is
done?


Thanks,
Savita

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
Sent: Friday, October 06, 2006 3:06 PM
To: wes@xxxxxxxxxxxxxx; aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Custom JoinPoints

With respect to the original problem relating to join point, you are
right
that one could populate a custom type without having a custom JoinPoint.
I've used thread local stacks to record state at a join point for
subsequent
use and sharing, and that's certainly possible in this case. On further
consideration, I'm actually not sure whether Savita is hoping to store a
smaller data structure just while proceeding with the join point or even
wants to retain a trace after returning (say until the transaction
completes).

If constructing one while proceeding there's a trade off: either eagerly
construct a summary object and incur the performance hit of creating
thisJoinPoint (for summaries that need it) or construct one lazily and
pin
the memory that args use (since they might be needed later). I suspect
Savita would like a custom join point to be constructed lazily and to
avoid
pinning extra memory, but that would require more than a subclass, it
would
require only passing a subset of state when constructing a join point
(which
would be a lot more than allowing a custom join point class).

With respect to static state, it's often very desirable to store the
state
directly associated with an accessible object rather than using any kind
of
map structure. The most important reason is to avoid concurrency control
issues associated with thread-safe data structures, and the secondary
issue
is to get O(1) and not O(log n) access times. That's a big motivation
for
wanting per static part storage. 

I agree about collisions and Matthew posted some notes to the bugzilla
tracking entry about how one might allow aspects to each have their own
object. It would be worth somehow allowing aspects to "share tickets" so
they can correlate shared state at a join point or static part without
resorting to a map.

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Wes
Sent: Thursday, October 05, 2006 11:46 PM
To: aspectj-users@xxxxxxxxxxx
Subject: 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?

_______________________________________________
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