Oh, I just read this message after answering the previous one. Only to produce output for woven files sounds like a smart idea. I would love to see that as a feature. -- Alexander Kriegisch
> Am 08.11.2013 um 01:53 schrieb Andy Clement <[email protected]>: > > 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 <[email protected]> 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 <[email protected]> >>> 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 >>>> <[email protected]>: >>>> >>> >>>> 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 <[email protected]>: >>>>> >>>>> 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 <[email protected]> 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 <[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aspectj-users mailing list >>>>>> [email protected] >>>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>>>> >>>>> _______________________________________________ >>>>> aspectj-users mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
