Calling methods on guest language objects from host language

Jaroslav Tulach jaroslav.tulach at oracle.com
Wed Sep 2 14:00:56 UTC 2015


FYI: The eval method that returns Symbol is now in:
http://lafo.ssw.uni-linz.ac.at/hg/truffle/rev/d045a505c2b3
Please give it a try and let me know if it addresses your problem.
-jt

### Wednesday 02 of September 2015, 09:25:58 @ Jaroslav Tulach ###
> Hello Peter,
> thanks for using TruffleVM!
> 
> ### Sep 1, 2015, Peter Niederwieser ###
> 
> > I’m trying to make the following interaction between host language and my
> > own guest language work: Call TruffleVM.eval(), which returns a guest
> > language object, call a method on that object that returns another object,
> > call a method on that object, etc. This is effectively traversing a guest
> > language object graph that is computed lazily, which is a main way of
> > interacting with my guest language (i.e. I’m going to have lots of such
> > calls).
> 
> I assume host language is Java, right? So you'd like to make calls from Java
> into your TruffleObject. I am currently working on such kind of
> Java/Truffle interoperability.
> 
> > The problem I’m facing is that calling from the host language into the
> > guest language, either by invoking a CallTarget or sending a
> > TruffleObject message, doesn’t re-establish the VM context. The only way
> > I found to do that is to invoke a Symbol obtained with
> > TruffleVM.findGlobalSymbol(). However, my guest language objects aren’t
> > global symbols, but dynamically computed along the way.
> 
> You are right! Just directly calling TruffleObject will not set the context
> properly! I was not aware of this flaw. In spite of that I have a solution:
> as part of changes to introduce asynchronous execution I want to change the
> return value of eval to Symbol:
> http://source.apidesign.org/hg/truffle/diff/1601491ae7c3/truffle/com.oracle.
> truffle.api/src/com/oracle/truffle/api/vm/TruffleVM.java that would give you
> a way to invoke(...) operations with the correct TruffleVM context and (as
> invoke method now returns Symbol again), it would allow you to chain such
> invocations as many times as you want.
> 
> > For now, I hacked around this by manually creating a TruffleVM.Symbol
> > using
> > reflection (the constructor is non-public). Is there a better way, or can
> > one be added?
> 
> Your use-case is important, we have to address it somehow. I will try to
> merge my "TruffleVM.eval returns Symbol" changes today, we'll see if they
> work for you (or you can try revision 3c5aaa402a4e from
> http://source.apidesign.org/hg/truffle/ - that is the most recent one that
> is likely close to what will be merged).
> 
> > Am I using Truffle in an unanticipated way, or in a way that
> > does not make much sense?
> 
> The way you use it makes sense, but alas it was a bit unanticipated.
> 
> > Ideally, I’d like for calls from host language to
> > guest language to be as lightweight as possible.
> 
> There is another work in progress in Java/Truffle interop:
> http://source.apidesign.org/hg/truffle/file/256cd7fcd283/truffle/com.oracle.
> truffle.api.interop.java/src/com/oracle/truffle/api/interop/java/JavaInterop
> .java at the end the Symbol should have a method:
> 
> public <T> T as(Class<T> interopInterface) {
>   return JavaInterop.asJavaObject(interopInterface, get());
> }
> 
> which should make it even more easier to call TruffleObjects from Java.
> 
> Thanks again for using Truffle!
> -jt



More information about the graal-dev mailing list