diff src/share/vm/graal/graalVMToCompiler.cpp @ 9126:bc26f978b0ce

HotSpotResolvedObjectType: implement hasFinalizeSubclass() correctly don't use the (wrong) cached value, but ask the runtime on each request. Fixes regression on xml.* benchmarks @ specjvm2008. The problem was: After the constructor of Object was deoptimized due to an assumption violation, it was recompiled again after some time. However, on recompilation, the value of hasFinalizeSubclass for the class was not updated and it was compiled again with a, now wrong, assumption, which then triggers deoptimization again. This was repeated until it hit the recompilation limit (defined by PerMethodRecompilationCutoff), and therefore only executed by the interpreter from now on, causing the performance regression.
author Bernhard Urban <bernhard.urban@jku.at>
date Mon, 15 Apr 2013 19:54:58 +0200
parents 8bbbde9d0a52
children 2dc020b33a6e
line wrap: on
line diff
--- a/src/share/vm/graal/graalVMToCompiler.cpp	Fri Apr 12 11:06:19 2013 +0200
+++ b/src/share/vm/graal/graalVMToCompiler.cpp	Mon Apr 15 19:54:58 2013 +0200
@@ -208,7 +208,7 @@
   return (oop) result.get_jobject();
 }
 
-oop VMToCompiler::createResolvedJavaType(Klass* klass, Handle name, Handle simpleName, Handle java_mirror, jboolean hasFinalizableSubclass, jint sizeOrSpecies, TRAPS) {
+oop VMToCompiler::createResolvedJavaType(Klass* klass, Handle name, Handle simpleName, Handle java_mirror, jint sizeOrSpecies, TRAPS) {
   assert(!name.is_null(), "just checking");
   assert(!simpleName.is_null(), "just checking");
   JavaValue result(T_OBJECT);
@@ -218,7 +218,6 @@
   args.push_oop(name);
   args.push_oop(simpleName);
   args.push_oop(java_mirror);
-  args.push_int(hasFinalizableSubclass);
   args.push_int(sizeOrSpecies);
   JavaCalls::call_interface(&result, vmToCompilerKlass(), vmSymbols::createResolvedJavaType_name(), vmSymbols::createResolvedJavaType_signature(), &args, THREAD);
   check_pending_exception("Error while calling createResolvedJavaType");