JDK-8013168 : extend the set of code pointers from Method to support multiple architectures
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-04-24
  • Updated: 2017-02-20
  • Resolved: 2017-02-20
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
We need to store GPU/APU code on selected methods, independently of normal CPU code.

There are currently 5 words used in the Method struct to store code and structures relating to code.  Even if we support only one type of GPU this means something like 5 more words.

Let's think about merging all the pointers used to manage code (code, x_adapter, etc.) into a consolidated format that will save memory and allow new degrees of freedom.

(This is similar to the work in JDK-8010862 that consolidated the method counters.)

Note:  The OSR side table might be able to go away also if we do this right.

Consider an open api like:
  address Method::entry_point(enum EntryPointKind k, int subtype = 0)

(Subtype is usually zero but may be BCI for an OSR nmethod, or what-not.)

The data structure probably needs searching but can be organized so that search length is 1 almost always.  Compact the common cases.

EntryPointKinds for _code and for _gpu_code, for example.

(Definition of GPU could be, "whatever we found besides the CPU when the JVM started".  If there are up to 2 possibilities, CPU + GPU1 + GPU2, etc.)

Existing pointer words relevant to enum EPK:
{
  address _i2i_entry;           // All-args-on-stack calling convention
  // Adapter blob (i2c/c2i) for this Method*. Set once when method is linked.
  AdapterHandlerEntry* _adapter;
  // Entry point for calling from compiled code, to compiled code if it exists
  // or else the interpreter.
  volatile address _from_compiled_entry;        // Cache of: _code ? _code->entry_point() : _adapter->c2i_entry()
  // The entry point for calling both from and to compiled code is
  // "_code->entry_point()".  Because of tiered compilation and de-opt, this
  // field can come and go.  It can transition from NULL to not-null at any
  // time (whenever a compile completes).  It can transition from not-null to
  // NULL only at safepoints (because of a de-opt).
  nmethod* volatile _code;                       // Points to the corresponding piece of native code
  volatile address           _from_interpreted_entry; // Cache of _code ? _adapter->i2c_entry() : _i2i_entry
}
Comments
Either this is a duplicate of JDK-8038356 or the other way around.
28-03-2016