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

[Christian Thalinger]

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.
> 
> http://cr.openjdk.java.net/~jrose/6862576/webrev.00/
> 

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