Matthew Webster wrote: --------------- 6. Any implementation of custom JoinPoint instance factory would have to be transparent to other aspects in the system i.e. only the aspect that provides the factory would get the custom instances, other aspects would get the vanilla implementation. --------------- Given your answer to the magic slot, I'm surprised at this one.
Currently the same join point instance is shared by multiple advice in different aspects. So it should be the case, e.g., that a change made by around advice to replace an argument is visible to less precedent advice. (Right now I think there's a bug outstanding wrt this not being true for JoinPoint.getArgs(), but it is true for context passed in to advice.) Different join point instances would likely mean we can't rely on that invariant any more, with bad results. Instead, the purpose of making the custom join point binary compatible is to make sure it can be used by other advice and aspects. Which of course brings us back to the magic slot: who decides what custom implementation is used? It seems to me that sequestering context data (for memory management) together with a user-writable reference or hashtable would be the way to go. (The hashtable avoids contention but reintroduces the indirection some are trying to avoid.) That avoids the whole question of the AspectJ runtime relying on user classes. Wes ------------Original Message------------ From: Matthew Webster <[EMAIL PROTECTED]> To: [email protected] Date: Tue, Oct-10-2006 5:36 AM Subject: RE: [aspectj-users] Custom JoinPoints All, 1. Two different features: JoinPoint instances have the lifetime of the join point unless explicitly anchored by the aspect (I don’t understand the comment about setting thisJoinPoint to null, it’s essentially an advice method parameter). A custom JoinPoint implementation would store object references (this, target, args) differently according to the size of the object either by using a soft reference (of dubious value in a flight recorder) or an object identity. On the other hand it only makes sense to store user state in a JoinPoint.StaticPart instance and most of the discussion in Bug 89009 “Add ability to associate user object to join point” relates to such an implementation (it may make sense to change the title to avoid further confusion). 2. Any implementation of per-static join point object user data will ensure it can be used transparently by multiple aspects i.e. we should not have to ask the question: “who decides who gets the magic slot?” If aspects want to share state they can do so independently (and deal with the consequences). 3. The ability to store user state in a static join point instance will not solve the problem discussed on this thread. 4. I have already posted a solution to this thread (http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg06859.html) that requires no AspectJ API changes but instead proposes storing (rather than creating) a custom JoinPoint instance. I suggest this approach is tried and any drawbacks reported to the list. 5. I have also suggested an API for a custom JoinPoint factory (http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg06861.html). I think the author of this thread is soliciting comments on my proposal. I have opened Bug 160296 “Custom JoinPoint factory” but it is _very_ unlikely to make 1.5.3 because of timing and also requires at least two _compelling_ use cases before it is considered for implementation. 6. Any implementation of custom JoinPoint instance factory would have to be transparent to other aspects in the system i.e. only the aspect that provides the factory would get the custom instances, other aspects would get the vanilla implementation. 7. thisJoinPointStaticPart.hashcode() will always return the same answer for a given instance as this is part of the Java specification (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode()). We do not override this method in StaticPartImpl. Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, [EMAIL PROTECTED] http://w3.hursley.ibm.com/~websterm/ "Chandan, Savita" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/10/2006 07:58 Please respond to [email protected] To<[email protected]>, <[email protected]> cc SubjectRE: [aspectj-users] Custom JoinPoints Thanks Ron, I will try that. From: [EMAIL PROTECTED] on behalf of Ron Bodkin Sent: Sat 10/7/2006 1:59 PM To: [email protected] Subject: 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandan, Savita Sent: Friday, October 06, 2006 5:27 PM To: [email protected] 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: [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 _______________________________________________ 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 _______________________________________________ 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
