org.graalvm.compiler.nodes

Class GraphEncoder

java.lang.Object

org.graalvm.compiler.nodes.GraphEncoder

public class GraphEncoder
extends Object

Encodes a StructuredGraph to a compact byte[] array. All nodes of the graph and edges between the nodes are encoded. Primitive data fields of nodes are stored in the byte[] array. Object data fields of nodes are stored in a separate Object[] array. One encoder instance can be used to encode multiple graphs. This requires that GraphEncoder.prepare(org.graalvm.compiler.nodes.StructuredGraph) is called for all graphs first, followed by one call to GraphEncoder.finishPrepare(). Then GraphEncoder.encode(org.graalvm.compiler.nodes.StructuredGraph) can be called for all graphs. The objects and node classes arrays do not change anymore after preparation. Multiple encoded graphs share the Object[] array, and elements of the Object[] array are de-duplicated using Object equality. This uses the assumption and good coding practice that data objects are immutable if Object.equals(java.lang.Object) is implemented. Unfortunately, this cannot be enforced. The Graal NodeClass does not have a unique id that allows class lookup from an id. Therefore, the encoded graph contains a NodeClass[] array for lookup, and type ids are encoding-local. The encoded graph has the following structure: First, all nodes and their edges are serialized. The start offset of every node is then known. The raw node data is followed by metadata, i.e., the maximum fixed node order id and a "table of contents" that lists the start offset for every node. The beginning of this metadata is the return value of GraphEncoder.encode(org.graalvm.compiler.nodes.StructuredGraph) and stored in EncodedGraph.getStartOffset(). The order of nodes in the table of contents is the orderId of a node. Note that the orderId is not the regular node id that every Graal graph node gets assigned. The orderId is computed and used just for encoding and decoding. The orderId of fixed nodes is assigned in reverse postorder. The decoder processes nodes using that order, which ensures that all predecessors of a node (including all predecessors of a block) are decoded before the node. The order id of floating node does not matter during decoding, so floating nodes get order ids after all fixed nodes. The order id is used to encode edges between nodes Structure of an encoded node:

 struct Node {
   unsigned typeId
   unsigned[] inputOrderIds
   signed[] properties
   unsigned[] successorOrderIds
 }
 

All numbers (unsigned and signed) are stored using a variable-length encoding as defined in TypeReader and TypeWriter. Especially orderIds are small, so the variable-length encoding is important to keep the encoding compact. The properties, successors, and inputs are written in the order as defined in FieldIntrospection.getData(), NodeClass.getSuccessorEdges(), and NodeClass.getInputEdges(). For variable-length successors and input lists, first the length is written and then the orderIds. There is a distinction between null lists (encoded as length -1) and empty lists (encoded as length 0). No reverse edges are written (predecessors, usages) since that information can be easily restored during decoding. Some nodes have additional information written after the properties, successors, and inputs:

AbstractEndNode: the orderId of the merge node and then all phi mappings from this end to the merge node are written. LoopExitNode: the orderId of all proxy nodes of the loop exit is written.