Preexistence and concrete type analysis in the context of multiple inheritance
Bibliographic record
Abstract
In the framework of just-in-time compilation, preexistence is a property which asserts that the receiver of a given call site has been instantiated before the current invocation of the considered method [5]. Hence, preexistence is a mean to avoid such low-level repair techniques as on-stack replacement or code patching, when a method must be recompiled during its own activation, because a previous optimization such as devirtualization or inlining has been invalidated by a new class loading. In the original proposition, preexistence considers only values, its analysis is purely intra-procedural, and its result is immutable. In this paper, we reconsider all three aspects: we focus on types instead of values, especially on concrete types, and we accept a limited form of inter-procedural analysis, whose results can be, marginally, mutable. Moreover, while the original proposition considered only method invocation, we place ourselves in the context of full multiple-inheritance, where attribute accesses need to be optimized, too. Overall, we propose a static analysis at runtime, combining concrete types and preexistence. The former allow for more optimizations, while the latter provides the condition for applying these optimizations without any need for repair. We experimented the approach in the prototype of a virtual machine for the Nit language, and the results are really encouraging. In spite of the focus on multiple inheritance, and the experiment setting, this proposal could be applied to most languages with static typing and runtime systems like the Java virtual machine.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.005 | 0.013 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.002 | 0.001 |
| Science and technology studies | 0.001 | 0.005 |
| Scholarly communication | 0.004 | 0.010 |
| Open science | 0.002 | 0.004 |
| Research integrity | 0.001 | 0.004 |
| Insufficient payload (model declined to judge) | 0.003 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".