[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] Bytecode Caching in AspectJ
|
Oh and the best way to learn about what is in releases beyond 1.5.4 is
to skim the readmes. They aren't very verbose documents:
http://www.eclipse.org/aspectj/doc/released/README-160.html
http://www.eclipse.org/aspectj/doc/released/README-161.html
http://www.eclipse.org/aspectj/doc/released/README-162.html
etc to README-1612
http://www.eclipse.org/aspectj/doc/released/README-170.html
In 1.6.8 there was a major performance boost due to an internals
rewrite. And actually if you are seeing serialversionuid problems in
1.5.4 that may not contain all the fixes for the -XaddSerialVersionUID
feature. I would recommend upgrading if you can.
Andy
On 30 July 2012 18:08, Andy Clement <andrew.clement@xxxxxxxxx> wrote:
> IIRC you shouldn't have to turn permissions on to get it to run.
> However some of the configurable behaviour won't be configurable if
> you don't enable some permissions. For example AspectJ needs to be
> able to access system properties to check some configuration settings.
>
> What precise permission is it complaining about? (and where?)
>
> cheers,
> Andy
>
> On 29 July 2012 23:07, Jeevitha Muthusamy <mail2jeevithamk@xxxxxxxxx> wrote:
>> Thanks Andy !!
>>
>> We have faced java security permission issue while enabling Aspect code in
>> Websphere Application server.
>>
>> Is it mandatory to set java security permissions to enable aspects for
>> Websphere or for all application serversr??
>>
>> Please let me know some aspectj features since 1.5.4, that is applicable
>> and effective in Java 6.
>>
>> Thanks,
>> Jeevitha
>>
>>
>>
>> On Sat, Jul 28, 2012 at 4:10 AM, Andy Clement <andrew.clement@xxxxxxxxx>
>> wrote:
>>>
>>> On 23 July 2012 01:54, Jeevitha Muthusamy <mail2jeevithamk@xxxxxxxxx>
>>> wrote:
>>> > May I know what is Bytecode Caching in AspectJ1.7 and its benefits??
>>>
>>> The caching is currently best described here:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=367673
>>>
>>> It is a per classloader cache of woven bytecode that avoids re-weaving
>>> on subsequent restarts.
>>>
>>> > And when caching is enabled, what exactly is cached??
>>>
>>> Per the readme and that bug, the caching is enabled when you turn on
>>> the system property:
>>> -Daj.weaving.cache.enabled=true
>>>
>>> The woven bytecode is cached on a per classloader basis. On a
>>> subsequent JVM restart
>>> the cached woven bytecode will be used instead of repeating the weaving
>>> process.
>>>
>>> > What is the life of Caching? Is it automatically refreshed or is
>>> > Static?
>>>
>>> It is not a super intelligent cache. If the incoming classes change
>>> (in length) then the
>>> cache will not be used (as it looks like this class needs reweaving),
>>> but changing the
>>> set of aspects will not cause reweaving to happen (IIRC). So this is
>>> for a system
>>> that is pretty static in terms of aspects but you want faster startup
>>> on secondary starts.
>>>
>>> > Is there any Memory limit for Caching? ie. If only to certain extent
>>> > Caching is done or is unlimited??
>>>
>>> disk space is the limiting factor I believe.
>>>
>>> > Is there any constraints(Where this feature is most applicable? ) to
>>> > use
>>> > this feature?
>>>
>>> If you have a system where the set of aspects are fixed, this can work
>>> well for you.
>>> The bug report contains some performance metrics showing you the benefits.
>>>
>>> > It will be more helpful, if any use-cases provided or any documents
>>> > regarding this feature!!
>>>
>>> Unfortunately the only real docs are in the bugzilla, I haven't had the
>>> time
>>> to integrate anything into the main docs.
>>>
>>> There are further changes coming into this area on two fronts:
>>>
>>> - 'asynchronous' caching. It has become apparent that storing entries
>>> on the disk in the first start is a bottle-neck and slowing down that
>>> initial start. aynchronous caching will do the storing in a thread.
>>> - assume common aspects across all classloaders to give a further
>>> boost. If your system meets this requirement then the cache will
>>> actually be consulted during the initial start if it sees two
>>> classloaders loading the same class (only one will suffer the weaving
>>> cost). This can make the initial start faster than without caching
>>> (as well as speeding up the latter restarts).
>>>
>>> Andy
>>> _______________________________________________
>>> aspectj-users mailing list
>>> aspectj-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>