Most are around the suggestion of improving the HotSwap facility in Java.
For exampe:
* How badly do you want Hotswap to improve?
* PLEASE VOTE: the only JVM bug you'll ever really care about
* Gaining traction: HotSwap improvements,
etc.
I have to admit that a year ago I was probably one of the guys that were swearing the most over HotSwap's (and JVM(D/T)I's shortcomings when trying to stretch its (limited) boundries in AspectWerkz.
However, today I think that improving HotSwap and the APIs for bytecode instrumentation in general is a dead end road. It simply adds complexiety, memory overhead, performance overhead as well as introduces the multiple agents problem.
We need to raise the abstraction level and move away from bytecode instrumentation. There is a need for high level VM APIs similar to the one we have been working on in JRockit. For details on the problems with current approaches and how we solve this in a better way, read this article.
So, PLEASE, stop wasting time in discussing how to improve bytecode instrumentation (e.g. HotSwap, JVMTI etc.) and give us feedback on how to improve the high-level VM API in JRockit (the prototype is already available).
When on the subject on supporting scripting languages in Java is think that this proposal for adding a invokedynamic bytecode instruction is a step in the right direction.
I just finished rewriting the master template for the slides to follow a terra-cotta based color scheme. ;-)
This is actually my second week as a Terracotta employee and I am looking forward to the upcoming months. We are currently sketching on some very interesting new stuff, among other things, stuff tied to transparent runtime environments. More on that later.
I will, from now on, spend a lot of time in San Francisco, so if you are in the area, drop me an email and I will buy you a beer :-)
Just a warning: If it turns out that you have not tried Terracotta's Virtualization Server and its Distributed Shared Objects (DSO), you will most likely here me rambling about that it is The way of doing distributed programming in Java (e.g. clustering and caching) and why you have to give it a try.
I have had two great years at BEA. It has been a great experience to work at the Java Runtime Products Group (JRPG), (JRPG is the group that implements the JRockit JVM), not everyone gets the opportunity to work among so many extremely talented and smart people, and that is something that I am very grateful for. I have learned more in these two years that I had in my whole career.
I am also grateful for that JRPG has believed in AOP and my vision, so much and that they have allowed me to work full-time for two years to materialize them.
During this two year period we (Alexandre Vasseur and myself) have had the opportunity to participate in writing three important chapters in this story for AOP in Java:
1. The release of AspectWerkz 2.0
2. The merge of AspectWerkz and AspectJ
3. The support for AOP in the JRockit JVM (thanks to Joakim Dahlstedt)
It for sure has been a ride :-)
Thanks JRockit.
]]>For example, take a look at this little code snippet. This piece of Java code implements a Node, which has three methods (that is of our interest):
Object get(), void set(Object o) and void swap(Node n)
Here's the implementation:
public class Node {
private Object value;
public synchronized Object get() {
return value;
}
public synchronized void set(Object value) {
this.value = value;
}
public synchronized void swap(Node n) {
Object tmp = get();
set(n.get());
n.set(tmp);
}
... // remaining methods omitted
}
This class might look okay, but it actually suffers from potential deadlock. For example what happens if, one thread T1 invokes n1.swap(n2) while an other one T2 concurrently invokes n2.swap(n1) ?
Thread T1 acquires the lock for node n1, and thread T2 acquires the lock for node n2. Thread T1 now invokes n2.get() (in the swap(..) method). This invocation now has to wait since node n2 is locked by thread T2, this while the reverse holds for thread T2 (e.g. it needs to wait for node n1 which is locked by thread T1). Which means that we have a deadlock.
This program is however easily fixed by using the technique of totally ordering all objects in the system.
public class Node {
private Object value;
public synchronized Object get() {
return value;
}
public synchronized void set(Object value) {
this.value = value;
}
private synchronized void doSwap(Node n) {
Object tmp = get();
set(n.get());
n.set(tmp);
}
public void swap(Node n) {
if (this == n) {
return;
} else if (System.identityHashCode(this) < System.identityHashCode(n)) {
doSwap(n);
} else {
n.doSwap(this);
}
}
... // remaining methods omitted
}
In this program, all locks will be acquired in increasing order, guaranteed to be the same for all threads, and thereby avoiding deadlock situations.
]]>It allows you to (among many other things) to profile an application running in production with (almost) zero overhead (without shutting it down or any preparation whatsoever).
Bill Burke and Dion Almaer has already blogged about it.
If you are interested to find out more, we have set up a webinar demo that anyone can join. Drop me an email at [jboner AT gmail DOT com] and I will send you the 'dial in info'.
------
Update: here is the dial in info (no need to mail me):
---------------------------- Web Meeting --------------------------------- When: Wednesday, March 23, 2005 10:00 AM-11:00 AM (GMT-07:00) Arizona. Where: Dial In/Web Meeting Web Meeting Address: https://www.webmeeting.att.com Toll Free Dial In Number: (866)214-3176 Int'l Access/Caller Paid Dial In Number: (404)827-9098 ACCESS CODE: 5519740 --------------------------------------------------------------------------------