JDK-6422536 : (ann) {Constructor,Field,Method}.getAnnotation() cache conflicts with RedefineClasses()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6,7,8,9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2006-05-05
  • Updated: 2024-04-12
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.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
java.lang.reflect.{Constructor,Field,Method} objects are created with
annotations data embedded in the object instead of using a JVM entry
point to fetch the current annotations like java.lang.Class. This is
effectively a cache of the annotations data since RedefineClasses()
does not change the annotations data in place. RedefineClasses() attaches
new annotations data to the class when it is redefined.

In addition to this implicit cache, there is an explicit cache of objects
stored in the java.lang.Class object. Some of the elements like Constructors
and Methods should flushed upon a RedefineClasses() call. Currently fields
cannot be modified by RedefineClasses(), but that may change in the future.

Once new JVM entry points similar to JVM_GetClassAnnotations() have been
added to the VM, then java.lang.reflect.{Constructor,Field,Method} will
need to be modified to use those entry points. The counter field added by
6407335 (java.lang.Class.classRedefinedCount) should be used to determine
when the Constructor,Field,Method} annotations data needs to be refetched.

Constructor - needs JVM_GetMethodAnnotations() and
              JVM_GetMethodParameterAnnotations();
              does not need JVM_GetMethodDefaultAnnotations()
Field       - needs JVM_GetFieldAnnotations()
Method      - needs JVM_GetMethodAnnotations(),
              JVM_GetMethodDefaultAnnotations, and
              JVM_GetMethodParameterAnnotations()

From the VM's point of view, constructors are methods so we should be able
to use the same entry points.

Comments
EVALUATION The JVM entry points were added to the Solaris mapfile via the following delta: build/solaris/makefiles/SCCS/s.mapfile-vers: D 1.28 06/08/07 12:55:48 dcubed 37 36 00004/00000/00230 MRs: COMMENTS: 6422536/6422541 - export new JVM entry points. And to the Linux mapfile via the following delta: build/linux/makefiles/SCCS/s.mapfile-vers-product: D 1.14 06/08/07 12:54:10 dcubed 15 14 00004/00000/00258 MRs: COMMENTS: 6422536/6422541 - export new JVM entry points. It looks like these deltas were pushed in Mustang-B96 as a partial fix under this bug id.
22-09-2010

EVALUATION There's a problem with the mapfile for libjvm.so: the new hotspot entry points are not global, so libjava can't call into them. Once hotspot is fixed and at least one build promoted, the rest of this fix can go in.
07-08-2006

EVALUATION The Description section describes the solution well. Will use sun.misc.JavaLangAccess to provide classes in java.lang.reflect with access to Class's class-redefinition counter.
05-05-2006