Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8266497

Remove unnecessary EMCP liveness indication



    • Enhancement
    • Status: Resolved
    • P4
    • Resolution: Fixed
    • 17
    • 17
    • hotspot
    • None
    • b21


      EMCP methods are defined as:

        bool Method::is_running_emcp() const {
          // EMCP methods are old but not obsolete or deleted. Equivalent
          // Modulo Constant Pool means the method is equivalent except
          // the constant pool and instructions that access the constant
          // pool might be different.
          // If a breakpoint is set in a redefined method, its EMCP methods that are
          // still running must have a breakpoint also.
          return (_flags & _running_emcp) != 0;

      Before PermGen was removed, Methods* for redefined classes (old methods) used weak handles to keep track of which ones were still being referenced. The weak references were cleared when the Method* was not found by GC. This necessitated keeping track of which EMCP methods are live so that breakpoints can be added to them, and breakpoints are not added to the collected EMCP methods.

      When converting to explicit deallocation, old Method* aren't deallocated until none of the methods in the old class are running. When MetadataOnStackMark runs, marking the Method* on_stack also marks the constant pool on_stack, so InstanceKlass::purge_previous_version_list only looks for the constant pool on_stack bit before purging the entire old class, including all of the Method*s.

      In this change, the code retained the notion of only setting or clearing breakpoints in *running* EMCP methods. Setting or clearing breakpoints aren't harmful in non-running EMCP methods - an application can't tell this has happened and there isn't a performance reason not to do this. In the previous PermGen world, there was because the non-running emcp method could have been collected, so that's why the code was there.

      With Loom redefinition, in the current implementation, the on-stack marking is more coarse so this unnecessary code would have to be rewritten or removed, so might as well remove it now.


        Issue Links



              coleenp Coleen Phillimore
              coleenp Coleen Phillimore
              0 Vote for this issue
              3 Start watching this issue