ThreadLists fails with a "inconsistent results" error in nightly testing in the GC baselines. Here's an example:

http://gtee.sfbay/gtee/results/MUSTANG/NIGHTLY/VM-MAIN/2007-08-23/GC_Baseline-Xconc/vm/linux-amd64/server/mixed/vm-linux-amd64_server_mixed_MM_REGRESSION2007-08-23-21-14-59/java/lang/management/ThreadMXBean/ThreadLists.jtr

From Swamy:

Date: Thu, 23 Aug 2007 18:50:41 -0500


    Serviceability Group <jk-svc-  xxxxx@xxxxx  >
Subject: Re: MM_REGRESSION

5. GetThreadLists:
        Failure is reproducible using vmoption -XX:+UseConcMarkSweepGC
        flag.
                ThreadGroup.activeCount() returned 5
                ThreadMXBean.getThreadCount() returned 6

        I suspect ThreadMXBean is returning an extra thread which
        may not be part of main threadGroup. This happens only
        if we use the above mentioned vm option. Does this create
        any java thread?
                Also the ThreadGroup.activeCount() doc says the return
        value may be imprecise and it should be used for informational
        purpose only. So I suspect this could be a test bug.

        But I would like to find out what was the sixth java thread
        which is not visible to ThreadGroup.activeCount().
Posted Date : 2007-08-24 22:22:29.0

N/A

This bug was originally fixed using bug id 5047639. During the code 
re-roganization of GC thread code this fix to hide  Surrogate Locker 
thread got lost. Restored the deleted code.
Posted Date : 2007-08-31 20:09:31.0