Skip to main content

[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
>>


Back to the top