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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin Sent: Friday, October 06, 2006 3:06 PM To: [EMAIL PROTECTED]; [email protected] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wes Sent: Thursday, October 05, 2006 11:46 PM To: [email protected] 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" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [email protected] > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Wes > Sent: Thursday, October 05, 2006 5:36 PM > To: [email protected] > 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" <[EMAIL PROTECTED]> > > To: [email protected] > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, > Savita > > Sent: Thursday, October 05, 2006 11:22 AM > > To: [email protected] > > 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" <[EMAIL PROTECTED]> > > Date: Fri, 29 Sep 2006 17:56:48 -0700 > > Delivered-to: [email protected] > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Ron Bodkin > > Sent: Friday, September 29, 2006 10:42 AM > > To: [EMAIL PROTECTED] > > 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 [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
