WIP: Improvements for Relocatable Compilations Part 3 #2920
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
September 17, 2018 18:10
When the JIT heuristically decides to disable the SelectiveNoOptServer, it only does so on the JIT Options object. This commit also sets the option on the AOT Options object. Signed-off-by: Irwin D'Souza <[email protected]>
If the user specifies higher method counts, don't delay relocation and make the scount the same as the count. Signed-off-by: Irwin D'Souza <[email protected]>
28 tasks
dsouzai
changed the title
dsouzai
force-pushed
the
AOTImprovementsPart3
branch
2 times, most recently
from
9e93981 to
d38e950
Compare
added 12 commits
September 18, 2018 17:35
Signed-off-by: Irwin D'Souza <[email protected]>
In AOT, the compiler can only konw about classes that can be remembered (ie, stored in the Shared Class Cache (SCC)). However, for functional correctness, before loading an AOT compiled body, the code needs to be validated in order to guarantee that the assumptions made about the java environment during the compile run are still valid in the load run. Currently, there are two types of validations; Arbitrary Class validations and Class From Constant Pool (CP) validations. The former can only apply to classes the compiler gets by name, when the name is a string literal (eg a class loaded by the Bootstrap Class Loader). The latter is used for classes the compiler gets from the CP of another class. Many queries in the compiler that get Class by Name have a default parameter that can be set to vett the callsite for AOT. However, these validations are not sufficient to provide confidence to vett a site. The reason is because the query that gets the class by name is used when the class name string is parsed from the signature of method; in this case, the class that should be returned can be different depending on who the "beholder" is. Additionally, if the compiler finds a class that's not by name and not through a CP (eg string peepholes), then under the current AOT infrastructure, the class can't be used. This commit adds the infrastructure to enable validations of classes regardless of how the compiler acquired them. The infrastructure is general, in that it can be extended to enable validations of any kind of symbol that the compiler acquires that may be different or non-existent in the load run. The fundamental idea is to store validation records every time a front end query is made. The record holds information about the symbol acquired, how it was acquired, and what information is required to acquire it in the load run. Each symbol is given a unique ID. In the load run, the AOT validation infrastructure goes through the validation records and asks the same questions the compiler asked during the AOT compilation, and if the answers vary in any way, the AOT load fails. Otherwise, we are guaranteed that the code is entirely valid. For example, if the method being compiled is A.foo(), then before the compilation begins, the compiler creates: 1. Root Class Record for A 2. Method From Class Record for foo() This will result in A getting ID 1, and foo() getting ID 2. As the compilation continues, if the compiler gets class B in two different ways, namely once by name and once via CP, then two other records get created: 3. Class by Name for B 4. Class from CP for B and B gets assigned ID 3. In the AOT load run, all the AOT infrastructure can see are IDs. Therefore, it has to reconstruct the symbols from these IDs. First it goes through the Root Class Record, and determines what Class A is in the new environment. Then it goes through the Method From Class Record and searches for method foo(). Then it goes through the Class by Name record and determines what B is. Then it goes through the Class from CP record, and validates that the class it gets from the CP is the same as the class it got by name, since in the compile run, those two queries yielded the same answer. If after going through all the records everything stays consistent, then the load passes. An added subtlety that was not described in the example above is that whenever a class record is created, a class chain record is also created. The reason for this is because AOT can only work with classes that can be remembered. Additionally, the class chains ensure that the shape of the class is the same from run to run. Another subtlety comes from array classes. Because array classes don't have a unique ROMClass, the validation manager remembers the leaf component class, and stores as many Array Class from Component Class records as there are dimensions of the array class being validated. Signed-off-by: Irwin D'Souza
The Symbol Validation Manager is used to remember all the different ways the compiler acquired a symbol. However, there are regions where this information isn't necessary for the load run. For example, when asking for something from the Persistent CH Table, all that matters is the input to the query and the output; however, the query involves going through multiple classes before finally returning the answer. If the compiler were to store valiations for everything that occurs during this query, it would require consistency between the compile and load run for more than what is only required for the compilation. Therefore, this commit adds the means to denote regions that are not strictly necessary to validate for the load run. Signed-off-by: Irwin D'Souza <[email protected]>
Signed-off-by: Irwin D'Souza
Previously, because almost everything was "unresolved" under AOT, all calls would use the unresolved dispatch. However, with the new validations, very few unresolved pointers are only unresolved because of AOT. Therefore, generating an unresolved dispatch is incorrect. The solution to this problem is to assume, during an AOT compile, that all methods are interpreted. Thus, if a method is resolved, the compiler will generate a resolved interpreter dispatch snippet, which can patch the caller if/when the method is compiled. Signed-off-by: Irwin D'Souza <[email protected]>
Previously, Object Allocation Inlining under AOT maintained certain assumtpions about the trees that was only true if the class was unresolved. This commit fixes those assumptions. Signed-off-by: Irwin D'Souza
Signed-off-by: Irwin D'Souza <[email protected]>
Signed-off-by: Irwin D'Souza <[email protected]>
Signed-off-by: Irwin D'Souza <[email protected]>
Signed-off-by: Irwin D'Souza <[email protected]>
Signed-off-by: Irwin D'Souza <[email protected]>
Add query for when the compiler asks about whether a method is interpreted for heuristic reasons, and not for functional correctness reasons. Signed-off-by: Irwin D'Souzai <[email protected]>
dsouzai
force-pushed
the
AOTImprovementsPart3
branch
from
d38e950 to
2ba01e8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Depends on #2919 and eclipse-omr/omr#2979