3 Replies Latest reply on Jan 11, 2005 12:10 AM by Scott Stark

    In regards to Sun VM bugs 4670071 & 4699981

    David White Newbie

      ...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.

        • 1. Re: In regards to Sun VM bugs 4670071 & 4699981
          Scott Stark Master

          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.

          • 2. Re: In regards to Sun VM bugs 4670071 & 4699981
            David White Newbie

            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.

            • 3. Re: In regards to Sun VM bugs 4670071 & 4699981
              Scott Stark Master

              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.