for review (M): 6863023: need non-perm oops in code cache for JSR 292

Christian Thalinger Christian.Thalinger at Sun.COM
Mon Jul 27 04:10:53 PDT 2009

John Rose wrote:
> In order to inline method handles at invokedynamic instructions, it is  
> necessary to manipulate MethodHandle and CallSite constants from  
> generated code.  Since these objects are created by ordinary user code  
> and subject to usual GC, they are not preallocated in the perm gen.
> Currently compiled code requires that any oop embedded as an  
> instruction constant or any other nmethod part must be  
> OopDesc::is_perm.  For example, internal method objects and classes  
> and interned strings are permanent so that they can be manipulated  
> from compiled code.
> This restriction is a bug for JSR 292.  Luckily, there is a simple fix.

It seems there is a problem with returns:

+bool nmethod::detect_non_perm_oops() {
+  DetectNonPerm detect_non_perm;
+  if (PrintRelocations)  NOT_PRODUCT(detect_non_perm._print_nm = this);
+  oops_do(&detect_non_perm);
+  return detect_non_perm.detected_non_perm();
+    return false;
+  return true;

Shouldn't the compiler complain about that?

-- Christian

More information about the hotspot-compiler-dev mailing list