iterations <= limit
size <= n, but then checks if each iteration is needed with
size <= nhttps://github.com/oracle/truffleruby/blob/4c968f989656a1d77cbbd6edeb84610ae8bc8ed8/src/main/java/org/truffleruby/core/array/ArrayNodes.java#L2064-L2106
LoopExplosionKind.MERGE_EXPLODEfor bytecode interpreters), so it'd be helpful to get a list of involved nodes plus their iteration count (if that makes sense).
CompilerAsserts#partialEvaluationConstant). Is a PE constant always going to be a compilation constant? If yes, when can a non PE constant value be constant during compilation?
sulong/include/truffle.h? The 19.1.0 release, for example, does not deliver it ... (as it is internal, unstable, deprectated, ... API, presumably).
truffle_handle_for_managedwhich is only exposed via
truffle.h, isn't it? See https://github.com/oracle/graal/issues/1564#issuecomment-519914010
ValueWrapperManager, IIRC) from a Tcl command (C function
Polyglot_Cmd), to perform a reverse mapping of handle pointer to a Polyglot value.
truffle.h's on my own, to be honest.
polyglot_importto access a host object that acts as ValueWrapperManager, see the lines:
void *(*javaFunc)(ClientData cd) = polyglot_import("javaFunc"); javaFunc(cdata);
javacFuncis some reverse-mapper entity (this is the 2nd part to my puzzle),
cdatais the handle pointer in the sense of your
@rgoldberg the whole idea of Truffle centers around that you don’t need manual bytecode generation step. The main innovation of Truffle is you that write an interpreter and we infer the compiler from that. What that compiler compiles to is orthogonal, but very deeply integrated into the host virtual machine. Truffle relies on direct access to deoptimization/code invaliation which is not reasonably possible using normal bytecodes. In theory Graal could output byte code (which it currently doesn’t support), but that does not mean that this bytecode would behave like expected, as you need to find a way to implement deoptimization using bytecodes, which is not trivial and adds a lot of overhead.
The better and long-term viable approach for JVMs to support Truffle is to support JVMCI. JVMCI is part of OpenJDK and can be implemented by any JVM. By implementing JVMCI you also get Graal, the best in class Java JIT and support for all Truffle languages. While it is not trivial to implement JVMCI, the benefits may justify such a cost.
Besides all that, in order to actually get Graal to produce byte codes you already need to implement JVMCI, which already gives you Truffle native compilation support almost out of the box. So no further bytecode indirection needed.
Also note that Truffle compilation (partial evaluation ) is based on Java bytecodes with a few intrinsics, as Truffle interpreters are specified with bytecodes as special Java programs. So it is almost entirely covered by the JVM spec. We have a few minor areas where we diverge, and we want to cover these differences in some document soon.