|JVM options for OT/Equinox [message #770284]
||Fri, 23 December 2011 20:37
| Stephan Herrmann
Registered: July 2009
In a comment to my recent blog post I was asked:|
Can you think of any drawback of the needed VM options in the eclipse.ini (except that we need a Sun JVM >= 1.5.0_07, and it shoud not be activated on MacOSX) :
It seems I have never really documented why we use these options, so here you go:
In OT/Equinox when an bundle A declares an aspectBinding to a bundle B this creates a bi-directional dependency: A obviously needs to see B, but also the dispatch code woven into B needs to see A.
Such a cyclic dependency is perfectly legal in OSGi, but this doesn't play well with the strategy how a Sun/Oracle VM locks the class loader: deadlocks can easily result during class loading. Since locks are taken directly by the VM, not from Java code, the only way to avoid the deadlocks is by using the obscure options mentioned above (which obviously are platform dependent). This has been discussed in several bugs against Equinox and it has been reported that several projects successfully employ these options, I never heard of any problems caused by these options.
If you have the option to run on a Java 7 VM, there's good news: this VM now officially supports parallel class loading which should completely resolve the issue. I haven't yet made extensive experiments with this feature, though.
I am planning to release the next Topcased with those options so we can deploy easily specific hacks to our clients.
FWIW, OT/Equinox automatically sets these options when being installed, which is achieved by instructions to p2 (from a META-INF/p2.inf file). This means I don't actually see the need for setting the options in advance -- as soon as OT/Equinox is installed using p2 mechanisms, everything should be taken care of.
But again, I have never experienced any problems with these options nor have I heard of others reporting such problems.
Powered by FUDForum
. Page generated in 0.27151 seconds