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 <alexan...@kriegisch.name>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 <
> 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
>
>
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
