Do you have meth-link-7056328.patch applied? There's a bug in there with a
missing null check. A fastdebug build will assert like this:
(dbx) where
current thread: t@7
[1] __lwp_kill(0x7, 0x6), at 0xfeeb3ac5
[2] _thr_kill(0x7, 0x6), at 0xfeead5dd
[3] raise(0x6), at 0xfee68362
[4] abort(0x6, 0xfeaf1c48, 0xfe4c453c, 0xfe4d0037, 0xfa6918ec, 0xfe140f44), at
0xfee45e3d
=>[5] os::abort(dump_core = true), line 1869 in "os_solaris.cpp"
[6] VMError::report_and_die(this = 0xfa691b50), line 991 in "vmError.cpp"
[7] report_vm_error(file = 0xfe67c90e
"/home/ct232829/hsx/hotspot-comp/7056328/src/share/vm/runtime/handles.hpp",
line = 81, error_msg = 0xfe67c957 "assert(_handle != NULL) failed", detail_msg
= 0xfe67c976 "resolving NULL handle"), line 216 in "debug.cpp"
[8] Handle::non_null_obj(this = 0xfa691ca0), line 81 in "handles.hpp"
[9] constantPoolHandle::non_null_obj(this = 0xfa691ca0), line 195 in
"handles.hpp"
[10] constantPoolHandle::operator->(this = 0xfa691ca0), line 195 in
"handles.hpp"
[11] ciEnv::get_klass_by_name_impl(this = 0xfa692a44, accessing_klass =
0x83d6710, cpool = CLASS, name = 0x83d6a10, require_local = false), line 457 in
"ciEnv.cpp"
This piece of the patch for ciEnv.cpp should look like this instead:
@@ -451,6 +454,19 @@
}
}
+ if (found_klass() == NULL && !cpool.is_null() && cpool->has_preresolution())
{
+ // Look inside the constant pool for pre-resolved class entries.
+ for (int i = cpool->length() - 1; i >= 1; i--) {
+ if (cpool->tag_at(i).is_klass()) {
+ klassOop kls = cpool->resolved_klass_at(i);
+ if (Klass::cast(kls)->name() == sym) {
+ found_klass = KlassHandle(THREAD, kls);
+ break;
+ }
+ }
+ }
+ }
+
if (found_klass() != NULL) {
// Found it. Build a CI handle.
return get_object(found_klass())->as_klass();
Note the !cpool.is_null() part. Hopefully John will update the patch when he
gets a chance.
tom
On Jun 22, 2011, at 12:04 PM, Stephen Bannasch wrote:
> At 10:30 AM -0700 6/22/11, Tom Rodriguez wrote:
>> Could you provide more detail on this? I just ran the all these against
>> b146 and they all pass cleanly for a large collection of configs. One thing
>> you have to watch out for is an issue on 64 bit where the code cache fills
>> up because some ofthe stress tests use a lot of signatures. Run with
>> -XX:ReservedCodeCacheSize=128m until that issue is dealt with. You may also
>> need to increase the timeout for jtreg depending on the speed of your
>> machine.
>
> The problem appears to be the same for all the failures and is a segfault
> while compiling:
>
> #section:compile
> ----------messages:(3/189)----------
> command: compile
> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/lang/invoke/6991596/Test6991596.java
> reason: .class file out of date or does not exist
> elapsed time (seconds): 1.314
> ----------System.out:(18/764)----------
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x0000000101017a3d, pid=8795, tid=4501590016
> #
> # JRE version: 7.0
> # Java VM: OpenJDK 64-Bit Server VM (21.0-b15 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # V [libjvm.dylib+0x17a3d] ciEnv::get_klass_by_name_impl(ciKlass*,
> constantPoolHandle, ciSymbol*,bool)+0x4fd
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
>
> See more details: https://gist.github.com/1040828
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
