(imported from http://blogs.codehaus.org/people/avasseur, read comments there)
Samuel has done a viewlet where he demonstrates how to easily debug an application and its aspects with AspectWerkz from within Eclipse.
If you did not yet understood how standard and easy it was from my first annoucement, you have to watch it now !
All is explained step by step. This is a definitely a things to work with.
Friday, November 21, 2003
Wednesday, November 12, 2003
AspectWerkz announces support for BEA JRockit
(imported from http://blogs.codehaus.org/people/avasseur, read comments there)
The latest snapshot of AspectWerkz is now supporting JRockit JVM for on the fly weaving.
JRockit could not be supported before due to lack of HotSwap support and a limitation that forbids overriding of java.lang.ClassLoader with a -Xbootclasspath option. Users had to use offline mode until there.
The extension will be core part of coming 0.9 AspectWerkz release, so that all VM are supported with the smallest integration cost (Sun, IBM, JRockit).
Tests have been made with
- JRockit 7SP4 (java 1.3.1)
- JRockit 8.1SP1 (java 1.4.1_03)
The JMAPI JRockit API (management API) allows to add a classPreProcessor mechanism using a java snip or a command line option.
A single VM is thus running at full speed, both under java 1.3 and 1.4, without having to use bootclasspath override.
The classPreProcessor instance is responsible to modify bytecode of the class at load time. AspectWerkz was already providing this classPreProcessor based architecture since summer 2003 for Sun VM and Q3 2003 for IBM VM.
It is possible to hook or unhook AspectWerkz programmatically using JMAPI:
JVMFactory.getJVM().getClassLibrary().setClassPreProcessor(
new JRockitPreProcessor());
To launch a JVM with AspectWerkz hooked in for class load time weaving this consists of a single option:
/jrockit/bin/java
-Xmanagement:class=org.codehaus.aspectwerkz.extension.jrockit.JRockitPreProcessor ....
If you are a JRockit fan, please help us and give a try to AspectWerkz online mode by your own. We need your feedback to make it suits your needs.
We will provide extensive documentation with the 0.9 release, but for the impatient :
- grab a CVS snapshot
- check bin/aspectwerk scripts to adapt them for JRockit (one line is commented out - notice that AspectWerkz needs to be in bootclasspath due to JMAPI)
- have a look at org.codehaus.aspectwerkz.extension.jrockit.JRockitPreProcessor in src/extensions/
- compile extensions.jar with ant/maven aspectwerkz:extensions:compile
- give it a try
Monday, November 3, 2003
ThreadLocal and memory leaks
(imported from http://blogs.codehaus.org/people/avasseur, read comments there)
Last day I realized that using ThreadLocal can be very dangerous when it comes to long running applications and garbage collections.
When you read the documentation of the ThreadLocal, you read that the object put in a ThreadLocal context is associated to the thread, and will be garbaged once the thread is dead.
Each thread holds an implicit reference to its copy of a ThreadLocal as long as the thread is alive and the ThreadLocal object is accessible; after a thread goes away, all of its copies of ThreadLocal variables are subject to garbage collection (unless other references to these copies exist).
So if you use ThreadLocal to store some object instance there is a high risk to have the object stored in the thread local never garbaged when your app runs inside an app server like WebLogic Server, which manage a pool of working thread - even when the class that created this ThreadLocal instance is garbage collected.
To solve this issue, you will probably have to check for it first with a memory profiler tool like JProfiler, and then wrap the value put in the ThreadLocal in a WeakReference.
That did not appears to be obvious while reading the javadoc. Isn't it ?
Last day I realized that using ThreadLocal can be very dangerous when it comes to long running applications and garbage collections.
When you read the documentation of the ThreadLocal, you read that the object put in a ThreadLocal context is associated to the thread, and will be garbaged once the thread is dead.
Each thread holds an implicit reference to its copy of a ThreadLocal as long as the thread is alive and the ThreadLocal object is accessible; after a thread goes away, all of its copies of ThreadLocal variables are subject to garbage collection (unless other references to these copies exist).
So if you use ThreadLocal to store some object instance there is a high risk to have the object stored in the thread local never garbaged when your app runs inside an app server like WebLogic Server, which manage a pool of working thread - even when the class that created this ThreadLocal instance is garbage collected.
To solve this issue, you will probably have to check for it first with a memory profiler tool like JProfiler, and then wrap the value put in the ThreadLocal in a WeakReference.
That did not appears to be obvious while reading the javadoc. Isn't it ?
Subscribe to:
Posts (Atom)
Posts
