value type hygiene (original) (raw)
Remi Forax forax at univ-mlv.fr
Thu May 17 18:36:12 UTC 2018
- Previous message (by thread): methods with scalarized arguments
- Next message (by thread): hg: valhalla/valhalla: [LWorld] Value type array support for C2 (and lots of bug fixes)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
----- Mail original -----
De: "Roland Westrelin" <rwestrel at redhat.com> À: "John Rose" <john.r.rose at oracle.com> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net> Envoyé: Jeudi 17 Mai 2018 16:27:02 Objet: Re: value type hygiene
[moving to valhalla-dev]
When it comes to the calling convention, there's one extra bit of complexity: method handles. For a method handle invoke to a method m() with value arguments, there will be a lambda form with a call to a method handle linker. If the LF is compiled as a standalone compiled method, the JIT has no way to know values are expected by the method that's behind the linker method so it passes buffered values. If method m() is JIT'ed so it's expecting scalarized values, the method handle call fails. That problem is not specific to Lworld. It exists in MVT with _Value. We never solved it. But from previous discussions, it seems the way to solve that problem is for every method with value arguments to have 2 entry points: a scalarized values entry point and a buffered values entry point. In a first implementation, the buffered values entry point could fall back to the interpreter and the scalarized values entry point be eventually a JIT'ed method. Now assuming we have to have 2 method entry points, why not use the buffered value entry point when one of the value arguments is null (or maybe null)? What entry point to use at a call site could be decided at JIT compilation time: either all arguments are statically known to be non null and we can go with the scalarized values entry point or we fall back to the buffered values entry point. Whether the code being JIT'ed is legacy or not doesn't factor explicitly in the decision.
yes, that's the other solution, either you decide to use a signature (the first time you introduce a signature in the v-table) as proposed by John or you have a generic version and a specialized version. The former avoid to buffer every value types just because one may be null the later avoid weird NPE due the fact that a signature in a super type use a value type.
Given that NPEs only arrive due to separate compilation, i'm not sure which option is the best.
Roland.
Rémi
- Previous message (by thread): methods with scalarized arguments
- Next message (by thread): hg: valhalla/valhalla: [LWorld] Value type array support for C2 (and lots of bug fixes)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]