The fix for the following bug:

    6333838 3/3 reduce calls to fillInStackTrace()

has broken the following NSK test:

    nsk/jdi/ClassObjectReference/toString/tostring001

This test expects a single class named "java.lang.Object[]", but after the
fix for 6333838 there are now two classes with that name.

Here is a snippet from the test's .tlog file:

#Exception in thread "main" nsk.share.TestBug: found 2 such classes: java.lang.Object[]
# at nsk.share.jdi.Debugee.classByName(Debugee.java:135)
# at nsk.jdi.ClassObjectReference.toString.tostring001.execTest(tostring001.java:138)
# at nsk.jdi.ClassObjectReference.toString.tostring001.run(tostring001.java:94)
# at nsk.jdi.ClassObjectReference.toString.tostring001.main(tostring001.java:67)


Jim did some poking around and found that:

> It calls jvmti GetLoadedClasses which returns a
> a jclass at position 138 for [Ljava/lang/Object;]
> and then at the end of the returned list, there is
> a different jclass that is also for [Ljava/lang/Object;].

The fix for 6333838 added caching for java.lang.Object arrays so it looks
like that code has a problem.
This failure mode has also been observed in the following NSK tests:

    nsk/jdi/Accessible/isPackagePrivate/accipp001
    nsk/jdi/Accessible/isPrivate/isPrivate001
    nsk/jdi/Accessible/isProtected/isProtected001
    nsk/jdi/Accessible/isPublic/isPublic001
    nsk/jdi/ClassObjectReference/reflectedType/reflectype001
    nsk/jdi/ReferenceType/classObject/classobj001
    nsk/jdi/ReferenceType/equals/equals001
    nsk/jdi/ReferenceType/hashCode/hashcode001
    nsk/jdi/ReferenceType/name/name001
    nsk/jdi/ClassLoaderReference/visibleClasses/visibleclasses001