Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Dealing with wrapped classes

Before I previously responded I thought about the solution that involved maintaining a map/set of what you were interested in, but I didn't suggest it - I half think the overhead of the map lookup will be worse than the while loop - but I'll admit I haven't measured anything to confirm that.  Going down that route you could use a pertarget aspect to have AspectJ associate aspect instance state with the target objects of interest.

There is no machinery in AspectJ to help you take the relevant bits out of rt.jar but maybe you can do something with the maven plugin (send a subselection of the jar contents to ajc?).  On the command line I know I'd weave it then "jar -xvf rt.jar the/bits/I/need" then "jar -cvMf newjar.jar the/bits/I/need". That could get annoying depending on how many types you hit but I bet it can be kind of automated by using the -showWeaveInfo option to see which types really got modified then a bit of grep/cut/sed/awk/etc.  I wouldn't like to try and automate that approach in maven though.

I bet we have an enhancement request somewhere that says produce output only for files that get woven, it wouldn't really be that hard to implement.

cheers,
Andy


On 7 November 2013 14:58, Jonathan Mace <jcmace@xxxxxxxxxxxx> wrote:
Thanks Alexander.  I've been trying out weaving rt.jar and it's simple enough.  I build my project with maven and it's easy enough to weave rt.jar.  By default it does as you describe and includes the entire rt.jar in the output.  What is the ajc command line option (or aspectj-maven-plugin option) to do as you suggest?

Cheers,

Jon


On 7 November 2013 17:26, Alexander Kriegisch <Alexander@xxxxxxxxxxxxxx> wrote:
Oh, I forgot to mention a little trick I use often in situations like these: I do not create a full copy of rt.jar, but just a small jar of woven JRE classes which I *prepend* to the bootclasspath, so the classes therein are found by the system classloader *before* the ones in the original rt.jar.

-- 
Alexander Kriegisch


Am 07.11.2013 um 23:22 schrieb Alexander Kriegisch <Alexander@xxxxxxxxxxxxxx>:

Your intention is to profile low level calls. Whether you like it or not, I think weaving rt.jar is the best choice because it does not have as much overhead as the solutions you are thinking of. Profiling is usually not done in production environments, so weaving the JRE should not be too much trouble.

-- 
Alexander Kriegisch


Am 07.11.2013 um 21:56 schrieb Jonathan Mace <jcmace@xxxxxxxxxxxx>:

Thanks for your response Andy.

Consider the following alternative approach to 'marking' the instances I'm interested in.  I maintain a WeakHashSet<FilterInputStream> to reference all input streams that i'm interested in.  I weave all constructor calls to FilterInputStream, adding this new stream to the set if either a) it's filtering a FileInputStream or b) it's filtering another FilterInputStream that already belongs to the set. Then I weave all calls to FilterInputStream+.read(..), adding an if() in the pointcut to test for membership in the set.

It would suffer the same drawbacks of not instrumenting rt.jar, but would be pretty easy to implement.  But, would this impose a lot of additional overhead?

Cheers,

Jon


On 7 November 2013 15:48, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
 I'll also mention that I don't want to weave rt.jar.

Shame, that would make it rather easy with a pointcut on execution of FileInputStream+.read(..).

I can imagine your proxy route might work. You can advise the constructor calls to the various FilterInputStream and FilterOutputStreams, and there return a proxy with an additional marker interface. Sounds pretty messy compared to what you are already doing though...  There isn't anything special in AspectJ to help here, simply around advice on the constructor call to 'new' and then use cglib to generate the tagged proxy.  If some of those constructor calls are made inside rt.jar though, you won't be catching them. (similar to now where you won't be catching calls to read that are made inside classes within rt.jar)

cheers,
Andy


On 6 November 2013 14:29, Jonathan Mace <jcmace@xxxxxxxxxxxx> wrote:
Hi everyone,

Love AspectJ.  I work on end-to-end tracing using X-Trace, and AspectJ is an awesome mechanism to do some of the tracing that I'm interested in.

I'm trying to profile file accesses; specifically, calls to FileInputStream+.read(..) and FileOutputStream+.write(..).  However, in many cases, file streams are wrapped in filter classes, such as Buffered streams or Data streams.  The specific base classes that provide this mechanism are FilterInputStream and FilterOutputStream.  Often, multiple filter streams are applied recursively to some base stream, for example new DataOutputStream(new BufferedOutputStream(new FileOutputStream("myfile.txt")));

Is there a way to define a pointcut that matches any Filter stream, whose underlying stream is a File stream?  The naive solution I have so far is:

  Object around(FilterInputStream o): target(o) && call(* FilterInputStream+.read(..)) {
    InputStream base = o;
    while (base instanceof FilterInputStream)
      base = ((FilterInputStream) base).in;
    boolean isFileStream = base instanceof FileInputStream;
    
    if (isFileStream) {
      long start = System.nanoTime();
      Object ret = proceed(o);
      long duration = System.nanoTime() - start;
      // do profiling stuff
      return ret;
    } else {
      return proceed(o);
    }
  }

I'm worried about the overhead of recursively examining the filter streams to determine whether the base stream is a file stream.  I'll also mention that I don't want to weave rt.jar.  It would be great if I could insert some kind of proxy class when the appropriate Filter instance is created, then the pointcut can just look for the proxy class.

Cheers,

Jon

_______________________________________________
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



Back to the top