Initialize port library in compiler and JitBuilder

[0xdaryl]

Compiler technology is not initialized or torn down in the same functions as the rest of the components in OMR, specifically the functions OMR_Initialize_VM and OMR_Shutdown_VM in omr/startup/omrvmstartup.cpp.

Determine and implement the initialization and shutdown strategy for compiler technology.

This should be done as part of the port library integration with the compiler.

[nbhuiyan]

While it would be extemely convenient to have all OMR components start up and shut down from one location, there are some issues we would need to discuss in the compiler Architecture Meeting on April 27 2018 (#2422).

Currently, both the Test Compiler and JitBuilder initializes OMR Compiler by using the class CompilerEnv's constructor, and then calling its initialize() method.

J9 does the compiler initialization differently than the Test Compiler and JitBuilder. It extends the CompilerEnv class and introduces a new J9JavaVM * vm field in the constructor, and adds 2 fields: J9PortLibrary * const portLib and J9JavaVM * const javaVM. The portLib is obtained from the javaVM. The startup function for the Compiler, initializeJIT(J9JavaVM *vm) takes in the VM as the argument, and handles the initialization of the Compiler.

My initial approach involved having OMR's CompilerEnv take a VM as a constructor argument, so that OMR_Initialize_VM could simply call a startup function similar to initializeJIT in J9. The VM would already have an initialized OMR_Runtime member, from which we can obtain the OMRPortLibrary which the compiler would use. However, there is a drawback to that. Unless we allow multiple ways to initialize the compiler env, OMR Compiler consumers such as JitBuilder would now require a VM to initialize the OMR Compiler. It would no longer be as standalone and simple as it is currently.

[dibyendumajumdar]

Hi - I would like to add here that I am interested in using the JIT compiler outside of the OMR framework. From my point of view, the OMR framework should know about the JIT compiler but not the other way round - i.e. initialisation of the JIT compiler should not require any knowledge of the larger OMR framework.

[harryyu1994]

Hi, I went through the discussions/comments in the compiler Architecture Meeting on April 27 2018 (#2422) and also in this thread. It's still not clear to me what the decision was for initializing port library in OMR compiler. I'm currently implementing processor feature detection for OMR compiler which needs access to the port library. Do you guys have any suggestions on how the port library initialization should be done? @0xdaryl @nbhuiyan @rwy0717 @mstoodle ?

[fjeremic]

@0xdaryl could we schedule a discussion on the architecture meetings about this? @harryyu1994 is quite close to adding proper processor support in OMR and we will need to query things from the port library. We need to discuss how exactly we are to initialize the port library for use within the compiler.

[0xdaryl]

Yes, I already have "OMR initialization" tentatively pencilled in for the March 26 OAM. However, rather than just have another open discussion on it (which is what we had in 2019) I would rather use the ideas and opinions from the previous discussion as a starting point and come forward with a specific proposal to discuss. I was hoping to spend some time summarizing and preparing something in the week prior to that meeting, but if anyone feels strongly about producing a proposal to discuss feel free to do so.

[fjeremic]

@harryyu1994 is this something you can summarize given your experience with the topic? Let's lay out some structured discussion points on what was tried previously and what we need today.

[harryyu1994]

I don't think I have enough experience with this particular topic LOL and also don't have enough knowledge to have a say in this. But I will help with gathering old discussions and lay them out here when I have time.

[fjeremic]

@harryyu1994 have you had time to process some of the old discussions? If not I can listen to the old call as well and gather notes here for tomorrow.

[harryyu1994]

@harryyu1994 have you had time to process some of the old discussions? If not I can listen to the old call as well and gather notes here for tomorrow.

Nope, I haven't looked into it yet. I did listen to the old call a while back but there are many things that I don't fully understand. So if you have time you should do it. I think you would do a much better job than me on this..

[fjeremic]

I've gone through the recording and summarized the important discussions in bullet point form:

• Initial proposal was that compiler should get initialized as part of OMR_Initialize_VM
• Use InitializeJit function?
• OMR VM is meant to store global data accessible to all components
  • Suggestion that some of the structures used by compiler/JitBuilder can move into OMR VM
• What set of information should OMR VM contain?
• JitBuilder shouldn't be part of startup API, but perhaps compiler should
• The initialize APIs should be used to startup/shutdown individual components of OMR
• JitBuilder should be able to slot into the process of initializing it within a runtime, but we should also be able to handle initialization of just the JitBuilder component without a runtime
• Which compiler does the VM bring up?
  • Due to the way extended classes work each "thing" consuming the compiler is different, for example JitBuilder and TestCompiler both have their own notions of resolved methods, etc.
• If JitBuilder needs the port library then JitBuilder should initialize it
  • Or find one that is already initialized
    • How?
• Concerns of InitializeJit being a wrapper of VM startup because of multiple components then having to initialize OMR
  • For example JitBuilder and a GCBuilder would both want the port library and they would both initialize their own copy?
• Have one global static port library per process which everyone uses and lazily initializes?
• What about having InitializeJit have two overloads, one in which we supply the port library, and one in which the compiler initializes it's own?
  • Nazim mentions he tried that and it worked well
  • What if two port libraries then get initialized?
• Split startup into three tiers (in that order)?
  • Process startup (starts up port and thread for example)
  • VM startup (starts up GC for example)
  • VM thread startup (starts up GC environment and mutator model)
  • General agreement on this
  • Does OpenJ9 fit into this model?
    • Does it do anything that would not fit into the model proposed above?
  • What about circular dependency at different points in time?
    • Concerns that OpenJ9 went down the path of sequencing things in weird ways to work around this conceptual model
• Clear statement about the dependencies between OMR modules is needed (in diagram form?)
  • If JitBuilder needs the port library then that should be one the parameters for JitBuilder startup
  • Should be very explicit and obvious how each module interconnects
  • May result into components getting broken up into smaller pieces depending on how they fit in the initialization sequence
• How does options processing work in this model?
  • Potentially have an API that returns a struct of some reasonable default values, let the runtime alter it and parse their options in whatever way, then validate the struct still make sense, report errors and fail to startup, otherwise startup

The people who were most involved were @mstoodle @charliegracie @rwy0717 @0xdaryl @nbhuiyan. There seemed to be general consensus towards the end, however we should revisit that in case thoughts have changed in the last two years.

We have a very clear problem at hand. We have sunk all the processor detection in the compiler from OpenJ9 into OMR. The OMR compiler relies on the port library for answers to questions about the processor. We do not have a valid pointer to the OMR port library in the compiler. How do we get one?

[0xdaryl]

After discussing at today's OMR Architecture Meeting, we agreed that to help refine the design of initializing the port library within JitBuilder and the compiler that the next step should be a proof-of-concept prototype to provide a concrete implementation for everyone to see and discuss.

@nbhuiyan had a working proof-of-concept implementation that initialized the port library from within JitBuilder from a project he was working on 2.5 years ago. He has volunteered to dust off that code and contribute it as a starting point for finalizing the implementation.

The larger issue of OMR component initialization and orchestration is not intended to be solved with this work, so I will rename this issue to reflect the new focus.