TruffleStackTrace contains CallTargets and is not serializable

[Martin Entlicher]

Hello,

The exceptions thrown from languages should implement TruffleException 
and then when thrown, the throwable has the language stack information 
filled in automatically. This is the not-serializable TruffleStackTrace 
that you see. But you can retrieve the stack trace elements 
(TruffleStackTraceElement) from 
TruffleStackTraceElement.getStackTrace(Throwable).
The Node and RootCallTarget provides more generic information than some 
language-created stack frame String representation. You can extract the 
information you need to send across the network, the indexes and Source 
URI of Node.getEncapsulatingSourceSection() for instance, etc. Would 
that work for you?

Regards,
Martin

On 11.9.2017 00:36, amp+graal at singingwizard.org wrote:
> My group is working on an implementation of a distributed language in
> Truffle (distributed Orc,
> https://github.com/orc-lang/orc/tree/master/PorcE). We are using Java
> serialization to ship information between nodes and this includes
> errors. We have run into a bit of a problem.
>
> TruffleStackTrace is not serializable, because it contains CallTargets
> to represent the guest language call stack. CallTargets contain both the
> full Truffle AST and probably a lot of Graal-related execution
> information, so they cannot be serialized (understandably). However,
> this means that any exception that went through a Truffle CallTarget is
> no longer serializable for transport across the network.
>
> Is it recommended that the Truffle languages catch all exceptions which
> are escaping and rewrite those exceptions to include a higher-level
> guest language stack trace representation?
>
> I think it might better to have a generic Truffle/Polyglot VM
> representation for a guest call stack element. RootNode could have a
> method to provide it to TruffleStackTraceElement. Languages could
> subclass the generic class to specialize it for their language if needed
> as well. This would provide all the information that the guest language
> implementation thinks is important without also including (and holding
> references to) internal Truffle or Graal data structures.
>
> Should I create a Github issue for this? Or did I totally miss the point
> somewhere in this? :-)
>
> -Arthur
>
>