-
Enhancement
-
Resolution: Unresolved
-
P4
-
25
installedCode and its usage have evolved quite a bit since the early days so we should revisit its design to try to simplify it. We use it in several ways that possibly make the core API a little too fat. Primarily it's the result of a successful compilation and we use various methods to get the generated code and code installation address for printing. We also use it in the context of unit tests to execute test code. And finally we use it for fast dispatch to host compiled code in the context of truffle.
Because of our strategy for invalidating the verified entry point in HotSpot we have the HotSpotInstalledCode subclasses of InstalledCode so that HotSpot can manipulate them. In SVM, InstalledCode is freely subclassable which permits truffle OptimizedCallTarget dispatch to get at the entry point field in one load. In constrast, HotSpot must load the InstalledCode instance and then load the field. It would be nice to remove the requirement for this extra indirection. That extra load also complicates the special truffle dispatch point generated by the TruffleEntryPointDecorator subclasses since we have to insert load barriers on this read.
My thinking is that maybe we split the first 2 usages off from the third usage. For libgraal we already use a cooperative association between the InstalledCode and the nmethod, so we could make that the only implementation for the informational methods and executeVarargs which already requires VM call. Then we could have a new class like InstalledCodeInvoker that only contains the entry point field and is subclassable. There'd be some step to associate an InstalledCode with an InstalledCodeInvoker and the only thing the VM is responsible for is invalidating that single field.
Or maybe that's too complicated and there's some way we could squish the whole implementation down so that we don't need the special HotSpot subclasses anymore. All the functionality would become cooperative, except for the fast entry point. I'm not entirely sure why we have all those subclasses at this point.
Because of our strategy for invalidating the verified entry point in HotSpot we have the HotSpotInstalledCode subclasses of InstalledCode so that HotSpot can manipulate them. In SVM, InstalledCode is freely subclassable which permits truffle OptimizedCallTarget dispatch to get at the entry point field in one load. In constrast, HotSpot must load the InstalledCode instance and then load the field. It would be nice to remove the requirement for this extra indirection. That extra load also complicates the special truffle dispatch point generated by the TruffleEntryPointDecorator subclasses since we have to insert load barriers on this read.
My thinking is that maybe we split the first 2 usages off from the third usage. For libgraal we already use a cooperative association between the InstalledCode and the nmethod, so we could make that the only implementation for the informational methods and executeVarargs which already requires VM call. Then we could have a new class like InstalledCodeInvoker that only contains the entry point field and is subclassable. There'd be some step to associate an InstalledCode with an InstalledCodeInvoker and the only thing the VM is responsible for is invalidating that single field.
Or maybe that's too complicated and there's some way we could squish the whole implementation down so that we don't need the special HotSpot subclasses anymore. All the functionality would become cooperative, except for the fast entry point. I'm not entirely sure why we have all those subclasses at this point.