Thanks Ron, I will try
that.
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
_______________________________________________
aspectj-users
mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users