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