Including JITaaS network communication code in OMR

[mpirvu]

Soon we will start porting the JIT-as-a-Service (JITaaS) code to openj9 (https://github.com/eclipse/openj9/issues/6072). The network communication library from the JITaaS code is generic enough such that it can be included either in openj9 or in omr. One wrinkle is that it has a dependency on the protobufs library. This issue was created to gather input on whether we want this communication code at the omr level.

[0xdaryl]

Is the network communication code separated from the JIT code? i.e., something more suited to the port library, or perhaps a new "net" component?

Can you summarize the API that it provides to seed our discussion/thinking here?

[mpirvu]

There are 3 main classes: class J9Stream as a based class and J9ServerStream, J9ClientStream as derived classes.

class J9Stream
   {
protected:
   J9Stream();
   void initStream(int connfd);
   virtual ~J9Stream();
   template <typename T> void readBlocking(T &val);
   template <typename T> void writeBlocking(const T &val);
   }

class J9ServerStream : J9Stream
   {
public:
   J9ServerStream(int connfd, uint32_t timeout);
   virtual ~J9ServerStream();
   template <typename ...T> void write(J9ServerMessageType type, T... args);
   template <typename ...T> std::tuple<T...> read();
   // finishCompilation is a thin wrapper around write(....)
   void finishCompilation(many params specific to openj9); 
   void setClientId(uint64_t clientId);
   uint64_t getClientId() const;
   };

class J9ClientStream : J9Stream
   {
public:
   static void static_init(TR::PersistentInfo *info);
   J9ClientStream(TR::PersistentInfo *info);
   virtual ~J9ClientStream();
   template <typename ...T> void write(T... args);
   // buildCompileRequest is a thin wrapper around write(T... args)
   template <typename... T> void buildCompileRequest(T... args);
   void writeError(); // inform server to abort current compilation
   // read() reads the type of the incoming msg. Typically followed by getRecvData()
   // J9ServerMessageType is defined in compile.proto used by protobuf compiler
   J9ServerMessageType read(); 
   template <typename ...T> std::tuple<T...> getRecvData()
   };

The typical sequence executed by a client is:

// establish a connection by creating a J9ClientStream object
client = new (PERSISTENT_NEW) JITaaS::J9ClientStream(compInfo->getPersistentInfo());
// determine compilation parameters and send the compilation request
client->buildCompileRequest(method, clazz, .................);
// handle any queries from the server
// Typical seq: (1) client->read(); (2) client->getRecvData(...); (3) client->write(...);
while(!handleServerMessage(client, compiler->fej9vm()));
// read compilation result
auto recv = client->getRecvData<uint32_t, std::string, std::string, .......>();
// install compiled code into code cache

The sequence executed by the server has a large portion that is openj9 specific. 1) Listener thread listens for a connection, opens a socket and adds an empty compilation request into the compilation queue:

// 'handler' below is openj9 specific. It defines a virtual method called `compile()`
// which adds an empty compilation request into the compilation queue
J9CompileDispatcher handler(jitConfig, listenerThread); 
JITaaS::J9CompileServer server;
// open socket, wait for connection, create J9ServerStream, call handler->compile(stream)
server.buildAndServe(&handler, persistentInfo);

2) Compilation thread extracts request from compilation queue and performs a read for the compilation parameters:

 JITaaS::J9ServerStream *stream = entry._stream;
 auto req = stream->read<J9Method *, J9Class*, ................>();

[mpirvu]

openj9 has a network socket implementation in their port layer. As I understand this code is a bit stale and not tested at the moment. We could brush the code off and move it from openj9 into omr. Then, if the protobuf communication layer has value for the omr project, change it to use omrsock port and contribute it to omr.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment on the issue or it will be closed in 60 days.