In regards to Sun VM bugs 4670071 & 4699981

[dtabwhite]

...as well as: http://jira.jboss.com/jira/browse/JBJMX-38

I hope you don't think this is a useless rant... ;^)

Has there been any indications that Sun will *ever* try to address this
bug? I see that these issues have been accepted as bugs, but that was
over 2 years ago (and 2 major VM versions ago...) and it's unclear
whether they have *any* intention of actually doing anything about it...
(i.e. the number of votes it's gotten certainly has't moved them...)

Also, in regards to the attempted workaround in JBoss 3.2.3. I don't
believe the fix will work in all cases.

For example:

Suppose there are threads T1, T2 & T3 and that T1 is using UCL1 and T2
and T3 are using UCL2. Now suppose T1 and T2 enter into loadClass(...)
of UCL1 and UCL2 respectively (hence obtaining their locks). Now if T3
needs to load a class with UCL2 it will be blocked in the VM before even
getting into UCL2 loadClass (or loadClassInternal for that matter
because it seems the VM obtains the CL lock even before calling into
loadClassInternal...). If UCL1 and UCL2 need to delegate to each other
in T1 and T2, then it's possible for UCL2 to give up its lock thereby
allowing T3 to acquire the lock and have the VM throw the
ClassCircularityError (if T2 was in the middle of loading class Foo that T3
was also trying to load before it was blocked...). T3 is then an "innocent
bystander" in this scenario. I believe the attempted fix assumes that the
CCE occurs within the context of a UCL.loadClass(...) reentrant call.

We have been plagued by random ClassCircularityErrors at startup of
our server (we've used versions 3.0.8 and 3.2.3) and having evaluated
the UCL code and the attempted workarounds to the VM bug, I believe
the above scenario is a likely explaination.

Do this assessment sound correct?

If so, then I'm not sure that anything can be done about this at the UCL
level as it seems there's always the possibility for an innocent bystander
thread to get a CCE before the UCL has even been entered.

[starksm64]

No, there has been no indication that this will be fixed.

There was some additional simplification in 3.2.5 and 3.2.6 that further reduced the CCE problem, but there are still scenarios where it can occur. The workaround in that case is to simply preload the classes to avoid multiple threads trying to define the same classes.

[dtabwhite]

Scott,

Thanks for the reply. Given that there is still a problem here, do you feel that the suggested workaround should be put somewhere in your official documentation (i.e. provide some recommended ways to preload all your classes...)?

It seems to me that Sun has two problems:

1) They lock class loaders before even calling into loadClassInternal, thereby making it impossible for class loading schemes (like UCL/ULR) to lock on some higher level object.

2) That they're detecting CCE based on the assumption that the CL that they locked is never released during the load.

You guys obviously know all this, so I'm wondering if you have at least given thought to providing an alternative CL loading scheme (i.e. one that would trade the UCL flexibility for parent-delegation stability)? I understand the rationale behind the UCL scheme and if it weren't for the 2 issues above, I would have no problem with it. I also agree that the *real* bug here is in Sun's court. Meanwhile however, users of your app server will suffer from these random CCE issues with their only recourse being to "load all classes at startup" (which itself isn't garaunteed to work, as the problem could theoretically happen during a re-deployment scenario...). Maybe the suggested workaround should be to have a deployment options that loads all classes synchronously when a UCL is first created or a URL is added to a given UCL.

FWIW, we've actually chosen a different approach as a workaround to this problem.
(Note: I know this is a big time compromise and a bit of a hack!)
I modified some of the UCL classes to optionally create "root" classloader that each of the UCL instances set as their parent and which point at all the URLs that all of the UCLs point at. Then all classloading is done though this "root" classloader. This behavior is enabled/disabled through a system property. Now, this obviously makes things like CL isolation and re-deployment break as the root CL becomes essentially a single monolithic CL that loads everything. For our particular usage this was ok, but it is definitely not a general solution for everyone.

[starksm64]

You are free to replace the UnifiedLoader implementation with whatever you want using the jboss jmx system properties. Its planned to provide a more traditional parent/child class loading implementation in the not too distant future.