Weldon Washburn wrote:
Xiao Feng,
It would be great if you could publish something like a list of what tests
run. I tried to run "build test" on windowsxp 32 w/ gcv5. It looks like
all the [jvmti] tests using the JIT pass. For some yet to be discovered
reason, the test suite fails when it runs the JVMTI breakpoint1 test w/
interpreter.
JVMTI tests are quite special because it is a quite different execution
mode. I've made them the first in the "build test" run, but it doesn't
mean you should start investigation with them.
Try to use "build smoke.test" and "build kernel.test". These test suites
execute VM in normal conditions, and kernel tests are executed in 3
different mode (jet, opt, interpreter).
I don't think that this new GC issue has any relation to JVMTI (well, I
hope it doesn't). If it is reproducible on smoke or kernel tests, it
will be easier to localize the possible problem source.
Ivan has mentioned that there might be some problems with finalizers.
Smoke tests contain enough pretty stressing tests on finalizers which
may be used to reproduce the bug.
Incidentally, the test causes GCV5 to execute an assert(0) that seems
rather
strange. assert(0); on line 52 of lspace.cpp is hit. The size of the
object requested is: 0x40000018. This looks like it is a request to
create
an object that follows the conventions in Class.h. That is, Class.h line
883 says, "The next to high bit is set if allocation needs to consider
class_properties." However, the comment in lspace.cpp says, /* FIXME::
trigger collection */. Its probably not a situation that warrents a
collection but instead a request for uncommon object attribute such as
pinning maybe (??)
--
Gregory
