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 <jcm...@cs.brown.edu>:
>
> 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.clem...@gmail.com> 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 <jcm...@cs.brown.edu> 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@eclipse.org
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
