Comment 1 Martin Lippert 2006-12-13 05:47:05 EST

Added a parameter to the ICachingService interface to pass the modified classbytes to the caching service.

Comment 2 Martin Lippert 2006-12-13 05:48:48 EST

See also bug #167824

Comment 3 Martin Lippert 2008-01-12 14:46:22 EST

I changed the way the weaving process is skipped for already woven bytecodes from the cache.

In the past bytecodes were identified as from the cache by analyzing the first four bytes. If those bytes are standard Java bytecode format (the class file magic number), weaving was activated, otherwise skipped. This worked fine for the J9 cache implementation since it seems that the bytes returned from the J9 shared class cache is not real bytecode but some kind of id or something similar. In the case of general bytecode caching the cached bytecodes will be of the general class file format. This would break this mechanism.

Now the AspectJBundleEntry provides a method that tells the AspectJHook whether to weave the class (not from cache) or not (from cache). This is possible because the AspectJBundleEntry already knows whether the bytecode data comes from the cache or not. If the bytecode comes from the cache, weaving is skipped.

Comment 4 Heiko Seeberger 2008-01-16 16:46:22 EST

Created attachment 87105 [details]
CachingService bundle with test and demo bundles

I just finished my work on the common caching service. Attached you find an archive with the caching service bundle org.aspectj.osgi.service.caching as well as a test bundle and two demo bundles.

In order for org.aspectj.osgi.service.caching to compile you also have to remove the obsolete method ICachingService.hashNamespace() in org.aspectj.osgi as already discussed in the mailing list. I will also attach a patch for that.

I am lookin forward to getting some feedback on this.

Heiko

Comment 5 Heiko Seeberger 2008-01-16 16:48:09 EST

Created attachment 87106 [details]
Removes obsolete method ICachingService.hashNamespace()

See the discussion in the mailing list ...

Heiko

Comment 6 Martin Lippert 2008-01-17 16:36:07 EST

I looked at the caching service implementation briefly and have a few questions:

In the test plugin you are using JMock and Hamcrest. What are the licenses for those libraries? We might need to go through the IP process for these libs.

You are collecting the cached bytecodes for the whole system in memory until the caching service is stopped. This possibly uses a lot of memory and might cause footprint problems for larger systems. I think we need to improve this to write cached bytecodes to disk on a regular basis (after every class, after every 10 or 50 classes, don't know yet).

You are not yet using the "key" parameter which is an indicator for the aspect configuration of the system. I would suggest that we create subdirectories for each configuration with maybe this "key" as directory name and store and read cached bytecodes from the specific cache directory matching the key.

In addition to this we should add the version information to the bundle cache file name in addition to the symbolic name to make sure that the caching service reads the bytecodes from the correct version of the bundle (this becomes interesting if new versions of bundles are getting installed).

Comment 7 Martin Lippert 2008-01-24 03:54:55 EST

I added the handling of the "key" parameter to the caching service and committed this into HEAD.

Test cases and examples not yet in the repo, they need some work and possibly IP process for some libs.

Will close this bug as fixed and open new bugs for improving the caching services (footprint, invalidation, version-handling of cached bundles, etc.).

Comment 8 Martin Lippert 2008-01-24 03:55:59 EST

The new bundle is named "org.aspectj.osgi.service.caching" and is located in "equinox-incubator/aspects".