Bug ID: JDK-6863023 need non-perm oops in code cache for JSR 292

JDK-6863023 : need non-perm oops in code cache for JSR 292

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 7

Priority: P3
Status: Closed
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2009-07-22
Updated: 2011-03-08
Resolved: 2011-03-08

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6	JDK 7	Other
6u21Fixed	7Fixed	hs17Fixed

Related Reports

Relates :	JDK-6940520 - CodeCache::scavenge_root_nmethods_do must fix oop relocations
Relates :	JDK-6885169 - merge of 4957990 and 6863023 causes conflict on do_nmethods
Relates :	JDK-6876684 - Generalize is_scavengable() interface in CollectedHeap (and rename).
Relates :	JDK-6962931 - move interned strings out of the perm gen
Relates :	JDK-7028374 - race in fix_oop_relocations for scavengeable nmethods

Description

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.

Comments

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/148e5441d916

16-09-2009