(imported from http://blogs.codehaus.org/people/avasseur, read comments there)
Since end of july the JSR 163 draft is in public review. I did not had time to read it before (shame on me !) and Jonas has send me the link yesterday.
(read the draft)
I am pretty happy with it. As you might know, we have struggled hard in AspectWerkz to provide a way to weave class at load time and keep compliant with complex class loader hierarchies as J2EE ones.
If JMangler was good for first AspectWerkz releases (prior to 0.8), having our own architecture was a major step forward (and read recent post on JMangler lists that state problems under J2EE environment where it is reported to freeze - as I reported it in Q2 2003).
On july 30 I complained about JVMPI API and was kidding at Sun, since they had forgetted some information I needed in the API.
(old article)
I forgot to subscribe to JSPA to gain access to JSR for early reviewing. I should have (shame on me!)
This JSR 163 sounds really good.
- First I will have the information I need in the class load hook event.
- Second, there seems to have support for in process hotswapping
- Last and not least, there seems to have no requirements for -Xdebug for the hotswapping part.
So adopt AspectWerkz online architecture today and you will have a preview of what this JSR 163 is going to provide in a simpler way for java 1.5. I have already a todo list for AspectWerkz online architecture when this java 1.5 will be ready for prime time.
And don't forget: subscribe to JSPA. I have sent the agreement to SUN this sunday !
Monday, October 20, 2003
Wednesday, October 1, 2003
An old crap we don't care about anymore
(imported from http://blogs.codehaus.org/people/avasseur, read comments there)
With the 0.8 release and the new online mode architecture, a major limitation has been resolved. Now online mode (on the fly weaving) can be enabled with application servers (was released summer 2003).
Prior to 0.7.4 (including 0.7.4), it was not working correctly on some circumstances, due to a problem in the JMangler architecture which was used for online mode. You could use AspectWerkz offline mode as a fix to this.
Starting with 0.8, we have developped in AspectWerkz our own architecture, that fix the problem and brings much more functionnalities. AspectWerkz hook architecture is now used in CGLib as well since we made it available as a standalone module.
Some recent post on JMangler mailing lists reminded me this problem, and i want to give you some focus here about this topic, even if its an old story I don't care about anymore since the AspectWerkz way is now far from those limitations.
The problem was that JMangler is using a JPDA LaunchingConnector. This is a Sun provided JDI component that allow to launch a JVM in debug mode from a first JVM. The first JVM is responsible of hooking the low level layer in the second JVM when this one starts up. This interesting architecture provided by JMangler team has many problems.
The major one makes it bogus under heavy class loading scheme, where the application launched loads lots of class in a multi threaded way. This heavy class loading can appear when an application server starts. Lots of class are created and some execute thread queues are initialized, threads deploy applications, jdbc drivers are loaded ...
I did some test under a weblogic 7 startup sequence, and it just hangs. Hopefully AspectWerkz now works perfecly fine with the new 0.8 architecture.
If you are interested in reproducing the bug, which seems to be a JPDA bug that thus affects the whole JMangler 3.x architecture and thus AspectWerkz version prior to 0.8, you can use the following sample application (read the extended entry below).
Download the test application
Read more about AspectWerkz 0.8
Read more about the new on the fly weaving architecture
Description of the testing application:
A sample main class application starts T threads (configurable).
Each thread runs L loops (configurable).
At each loop the thread instantiates a new URLClassLoader with a search path on file system from which it loads a single class and instantiate a first instance. The class static init section (clinit) loads itself another class using another new URLClassLoader.
Each class loading is written on stdout: classname + hashcode. Hashcode allows to identify classes loaded by differents classloader which are not hierarchically linked.
This simulates a startup sequence where a big number of class is loaded by several threads ( 2 x T x L class). No class reference is kept so all are elligible to garbage collection.
Results
The app performs well with 3 threads and 2000 loops (thus 12 000 class loaded) (use a heap of 128m and a new of 32m, used -verbose:gc option). Turning on -Xdebug or -Runjdwp does not affect the correct behavior.
When started thru JMangler or used with a jpda LaunchingConnector - the component used in JMangler 3.x - it does not complete, and the launching VM garbage collection sometimes turns completely crazy making a lot of minor garbage collections at around 6000 class loaded, and the whole app always hangs.
Tests were run under win2000 SP3 and solaris, under different java 1.4 version, with the same results.
Explanation
I don't have explanations. AspectWerkz 0.8 uses a ListeningConnector coupled to an AttachingConnector instead, and it performs fine.
Now you can startup a complete application server with AspectWerkz hooked in in online mode with a minimal overhead.
And the 0.8 release comes with many more options on this important topic, that makes AspectWerkz on the fly weaving an easy and non intrusive operation.
Download the test application
Read more about AspectWerkz 0.8
Read more about the new on the fly weaving architecture
With the 0.8 release and the new online mode architecture, a major limitation has been resolved. Now online mode (on the fly weaving) can be enabled with application servers (was released summer 2003).
Prior to 0.7.4 (including 0.7.4), it was not working correctly on some circumstances, due to a problem in the JMangler architecture which was used for online mode. You could use AspectWerkz offline mode as a fix to this.
Starting with 0.8, we have developped in AspectWerkz our own architecture, that fix the problem and brings much more functionnalities. AspectWerkz hook architecture is now used in CGLib as well since we made it available as a standalone module.
Some recent post on JMangler mailing lists reminded me this problem, and i want to give you some focus here about this topic, even if its an old story I don't care about anymore since the AspectWerkz way is now far from those limitations.
The problem was that JMangler is using a JPDA LaunchingConnector. This is a Sun provided JDI component that allow to launch a JVM in debug mode from a first JVM. The first JVM is responsible of hooking the low level layer in the second JVM when this one starts up. This interesting architecture provided by JMangler team has many problems.
The major one makes it bogus under heavy class loading scheme, where the application launched loads lots of class in a multi threaded way. This heavy class loading can appear when an application server starts. Lots of class are created and some execute thread queues are initialized, threads deploy applications, jdbc drivers are loaded ...
I did some test under a weblogic 7 startup sequence, and it just hangs. Hopefully AspectWerkz now works perfecly fine with the new 0.8 architecture.
If you are interested in reproducing the bug, which seems to be a JPDA bug that thus affects the whole JMangler 3.x architecture and thus AspectWerkz version prior to 0.8, you can use the following sample application (read the extended entry below).
Download the test application
Read more about AspectWerkz 0.8
Read more about the new on the fly weaving architecture
Description of the testing application:
A sample main class application starts T threads (configurable).
Each thread runs L loops (configurable).
At each loop the thread instantiates a new URLClassLoader with a search path on file system from which it loads a single class and instantiate a first instance. The class static init section (clinit) loads itself another class using another new URLClassLoader.
Each class loading is written on stdout: classname + hashcode. Hashcode allows to identify classes loaded by differents classloader which are not hierarchically linked.
This simulates a startup sequence where a big number of class is loaded by several threads ( 2 x T x L class). No class reference is kept so all are elligible to garbage collection.
Results
The app performs well with 3 threads and 2000 loops (thus 12 000 class loaded) (use a heap of 128m and a new of 32m, used -verbose:gc option). Turning on -Xdebug or -Runjdwp does not affect the correct behavior.
When started thru JMangler or used with a jpda LaunchingConnector - the component used in JMangler 3.x - it does not complete, and the launching VM garbage collection sometimes turns completely crazy making a lot of minor garbage collections at around 6000 class loaded, and the whole app always hangs.
Tests were run under win2000 SP3 and solaris, under different java 1.4 version, with the same results.
Explanation
I don't have explanations. AspectWerkz 0.8 uses a ListeningConnector coupled to an AttachingConnector instead, and it performs fine.
Now you can startup a complete application server with AspectWerkz hooked in in online mode with a minimal overhead.
And the 0.8 release comes with many more options on this important topic, that makes AspectWerkz on the fly weaving an easy and non intrusive operation.
Download the test application
Read more about AspectWerkz 0.8
Read more about the new on the fly weaving architecture
Subscribe to:
Posts (Atom)
Posts
