Final State of Project
This document marks the state of Eclipse OMR after my contributions to implementing OMR's variability using dynamic polymorphism instead of static polymorphism.
It was agreed upon during the OMR Compiler Architecture Meeting that after virtualizing all overridden functions in the 20 class hierarchies with the highest number of overridden functions, benchmarks will be performed on OMR. Accordingly, a decision will be made whether to accept the change in the project's variability implementation or not.
The virtualization process I've used is documented in a wiki page. I've also created this table which shows each class hierarchy and the number of overridden functions inside it. After inspecting some of the class hierarchies for virtualization, I've realized that the numbers in this table are not accurate with the updated OMR source code, but it can be referred to as a rough estimate of what hierarchies have higher number of overridden functions than others.
Based on that table, I've virtualized the overridden functions of 4 class hierarchies. I also removed the self() keyword from member function calls in those class hierarchies in the OMR project. The future work for this project is:
- Remove the rest of the
self()occurrences in the virtualized class hierarchies in OMR. I only removed theself()in member function calls which appear in the form ofself()->. However,self()can appear in function call parameters likeboo(self()). I did not handle those cases. This is explained more in the design challenge section of this document. - Remove all
self()occurrences in the virtualized class hierarchies in OpenJ9. - Continue virtualizing the overridden functions in the rest of the 20 class hierarchies.
Detailed information about each class hierarchy can be found in doc/virtualization. A summary of each class hierarchy's state is found below.
- 199 functions were virtualized
- 3 functions were declared as pure virtual since they had no implementation in the base class.
-
CodeGeneratorconstructor was staged into a two-phased initialization. More information about the background for this change can be found in this issue. - 2 local variables in member functions were renamed (
compandmachinewere renamed tocompilationandthisMachinerespectively) a function (OMR::CodeGenerator::insertInstructionPrefetches()) was declared to solve consequences of removingself()from member function calls (more info) - OMR PR | OpenJ9 PR
- 6 functions were virtualized
- 3 functions were ignored for being static
- 1 problematic function, solved by changing the name of
OMR::AutomaticSymbol::getKind()in this PR - Removing
self()from virtual member function calls builds and passes all the tests. However, removingself()from all function calls (even non-overridden ones) is still not compiling successfully (error can be found in the corresponding PR). This is not resolved yet. - OMR PR | OpenJ9 PR
- 1 function was virtualized
- Since this class hierarchy is simple and has only 1 overridden function, it was the first class hierarchy whose overridden functions were virtualize; it was used as an example to experiment with virtualizing functions and establish a systematic process
- OMR PR
As mentioned earlier, some of the self() functions appear in function call parameters, such as _machine = new (trHeapMemory()) TR::Machine(self()); (source). In this case, replacing self() with this would give a compilation error since the TR::Machine constructor expects a TR::CodeGenerator* and not OMR::CodeGenerator*. This can be solved in two ways:
- Replace
self()with a static cast toTR::CodeGenerator - Change the
TR::Machineconstructor, which would change the API of OMR.