Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Fabio Niephaus
    @fniephaus
    What's a good strategy to debug an too many loop explosion iterations error? I know what part of my codebase is causing the error, I'd like to understand why.
    Chris Seaton
    @chrisseaton
    It's just iterations > limit - not sure what else to say about 'why'
    So you need to ensure yourself that iterations <= limit
    It shouldn't depend on user input, for a start
    What I sometimes do I unroll a constant amount, and then check if the iteration is needed for the dynamic data structure each time
    For example this sort routine is exploded to n iterations if size <= n, but then checks if each iteration is needed with size <= n https://github.com/oracle/truffleruby/blob/4c968f989656a1d77cbbd6edeb84610ae8bc8ed8/src/main/java/org/truffleruby/core/array/ArrayNodes.java#L2064-L2106
    Fabio Niephaus
    @fniephaus
    @chrisseaton thanks, makes sense to not depend on user input. What I mean by 'why' is more info on what nodes are contributing to the loop explosion. The node where the explosion is reported has a limit of 3 (default) and does not depend on user code. but it's used quite often (for stack access). Other nodes seem to be able to "contribute" iterations (especially when working with LoopExplosionKind.MERGE_EXPLODE for bytecode interpreters), so it'd be helpful to get a list of involved nodes plus their iteration count (if that makes sense).
    Chris Seaton
    @chrisseaton
    Are you mean you're not even sure exactly what loop it is?
    Fabio Niephaus
    @fniephaus
    @chrisseaton yes, I'm quite certain it's not the one that caused the error. maybe even a bug specific to MERGE_EXPLODE.
    Fabio Niephaus
    @fniephaus
    So even after working with Truffle for a while, I still don't fully understand the difference between a compilation constant and a partial evaluation constant (as in CompilerAsserts#compilationConstant vs. 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?
    Christian Humer
    @chumer
    Yes and yes.
    compilation constant means that we found it to be constant during PE or in some compiler phase. For example we could see the constantness through scalar replacement in the partial escape phase. It is very hard to predict that whereas PE constant typically immediately follows from truffle intrinsics.
    PE constantness should be used if possible. As it is easier to argue about. There are not many use cases for compilation constantness except testing
    Fabio Niephaus
    @fniephaus
    @chumer I'm trying to clarify that with a docs update. Unfortunately, simple language only uses compilationConstant and thus doesn't demonstrate a good use case for partialEvaluationConstant
    Stefan Sobernig
    @mrcalvin
    How would I obtain a Graal installation that includes sulong/include/truffle.h? The 19.1.0 release, for example, does not deliver it ... (as it is internal, unstable, deprectated, ... API, presumably).
    Christian Humer
    @chumer
    @mrcalvin truffle.h was replaced with polyglot.h. It was deprecated for a while but got now replaced. It should be mostly a 1:1 migration. polyglot.h will have longer term support.
    @fniephaus which usage do you mean? Well for most use-cases you don’t need it. It is really an advanced API.
    Stefan Sobernig
    @mrcalvin
    @chumer I am aware, but @rschatz pointed me to using truffle_handle_for_managedwhich is only exposed via truffle.h, isn't it? See https://github.com/oracle/graal/issues/1564#issuecomment-519914010
    Christian Humer
    @chumer
    I see. pinged @rschatz to respond.
    Chris Seaton
    @chrisseaton
    @mrcalvin I would possibly recommend implementing handles in your interpreter if you need them. I don't think they're very general.
    Stefan Sobernig
    @mrcalvin
    @chrisseaton I am afraid, I don't follow :)
    Are you suggesting to implement some handle management for my case?
    Chris Seaton
    @chrisseaton
    Walking it back, what you want is handles for something, not truffle.h's handles specifically. What do you want handles for?
    Stefan Sobernig
    @mrcalvin
    Referring to my ticket (oracle/graal#1564), I need a way call back to an host entity (sth. akin of TruffleRuby's ValueWrapperManager, IIRC) from a Tcl command (C function Polyglot_Cmd), to perform a reverse mapping of handle pointer to a Polyglot value.
    Chris Seaton
    @chrisseaton
    Ah right this
    Stefan Sobernig
    @mrcalvin
    In short: I don' t want to rely on polyglot_import
    I don't see how I could implement a handle API like truffle.h's on my own, to be honest.
    Chris Seaton
    @chrisseaton
    Is the function itself still there? Can you write your own declaration for it until the new API arrives?
    Stefan Sobernig
    @mrcalvin
    oh, good point, did not check ...
    Chris Seaton
    @chrisseaton
    Implementing it is easy - it has a map of handle to object, and object to handle. Allocate handles from some memory you allocate. Or malloc each one for simplicity.
    Stefan Sobernig
    @mrcalvin
    I thought about implementing it on my own, but I figured I could not assign a managed object to some LLVM-side map (because of the boundary restrictions, the root cause of all of this).
    So, you say, I could implement LLVM-side ValueWrapper ...
    Chris Seaton
    @chrisseaton
    Ruby does it without any special help from LLVM.
    Stefan Sobernig
    @mrcalvin
    As I wrote, I got the ValueWrapper part, but this is only one part of my puzzle. The second is access to the ValueWrapperManager, to run the reverse mapping. This is sth. that must be done from the LLVM-side of things.
    (as opposed to TruffleRuby, this is where our cases diverge)
    I need sth. other than polyglot_import to access a host object that acts as ValueWrapperManager, see the lines: void *(*javaFunc)(ClientData cd) = polyglot_import("javaFunc"); javaFunc(cdata); javacFunc is some reverse-mapper entity (this is the 2nd part to my puzzle), cdata is the handle pointer in the sense of your ValueWrapper.
    Chris Seaton
    @chrisseaton
    Ah I see
    Stefan Sobernig
    @mrcalvin
    @chrisseaton The truffle.h functions are still provided, so I will fall back to local declarations for the time being. thx for this valuable hint!
    Ross Goldberg
    @rgoldberg
    Can Truffle output bytecode? Or does it only output machine code?
    If the latter, are there any plans to possibly output bytecode in the future?
    Boris Spasojevic
    @boris-spas
    @rgoldberg not sure what you mean. Could you elaborate?
    Chris Seaton
    @chrisseaton
    We used to discuss this - and some other Java people have discussed it as well - the idea is instead of sending the PE'd graph into Graal, convert it back to Java byte code and let C2 or whatever compile it.
    Ross Goldberg
    @rgoldberg
    @boris-spas Can someone use Truffle to implement a compiler from source into bytecode (i.e. .class files) that can then be used on any JVM? Or does Truffle only output binaries that only run within the GraalVM?
    @chrisseaton It seems like you’re saying this isn’t yet implemented, but has been discussed, and might be implemented sometime in the future. Is that correct? How hard would it be to add this feature?
    Chris Seaton
    @chrisseaton
    I think people have only thought about building toys. If you want to try it you'd need to do it yourself.
    Christian Humer
    @chumer

    @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.

    Fabio Niephaus
    @fniephaus
    Somewhat related side note: I'd like to see an LLVM or C backend for native image, so I can run native images on Sulong 🙃
    Fabio Niephaus
    @fniephaus
    @chrisseaton oh wow, why have I missed that. thanks for the pointer...now I only need to find out how to use it
    Chris Seaton
    @chrisseaton
    There used to be a JavaScript backend back in the day.