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 <alexan...@kriegisch.name>:
>
> 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
