Question about the new polyglot API and its `Value` class

[Christian Humer]

> What if after calling `context.enter()`, I would execute a node directly,
instead of using the polyglot API? Would this be enough to get
`TruffleContext` and time/memory boxing to work?

Yeah. I did not yet realize that this could solve your entire problem. ;-)

You could do :
Context context = Context.create();
context.initialize("yourlanguage");
context.enter();
// call to your language with your own API
// you should be able to access the current language context and
TruffleContext should work including instrumentation.
context.leave();
context.close();

Your language and truffle need to be put on the bootclasspath so you
language API is accessible from the application. (never tested that)

Does this help?

Cheers,
Christian



On Tue, Jan 16, 2018 at 8:44 PM Peter Niederwieser <pniederwieser at apple.com>
wrote:

> Hi Jaroslav and Christian,
>
> > - As far as I understand, Peter is not interested in an interface Pojo
> view
> > on JavaScript objects.
>
> That’s correct. Mapping Truffle objects to POJO views is nice but isn't
> applicable to my use case.
>
> > You can do a lot of language specific things without having an explicit
> API
> > for a particular language feature. For example it is also possible to
> > expose a guest language function that covers the language specific use
> > case. For example if we don't support removing of properties in the Value
> > API. Feel free to just do:
> >
> > Value removeProperty = context.eval("js", "(function(o, property) {remove
> > o[property];})");
> > removeProperty.execute(...)
> >
> > For example we used this trick to support certain things that are exposed
> > in the javax.scripting API but not yet in the Value API.
>
> This trick works for sufficiently powerful general-purpose languages but
> may not work for languages that are (intentionally) more limited.
>
> I used to think that a custom message would be a good fit for such a use
> case. However, last time I checked, the new `Value` API didn't support
> custom messages. (It also didn't support `invoke`.)
>
> > Accessing the raw object is problematic for multiple reasons:
> > - We need to enter a particular context for thread local context access
> > whenever we cross the boundary from host to guest. Your exposed raw
> object
> > is not doing that. All of our Java interop wrappers ensure that the right
> > context is entered.
>
> The raw object would only be accessed as part of evaluation within a
> context. It would be converted to an immutable data structure which would
> then be returned to the caller. The immutable data structure wouldn’t allow
> any further language interaction (so no further crossing of boundaries).
>
> > - It breaks the abstraction of the language implementation. (you make
> your
> > embeddings dependent on language implementation specific API)
>
> Only the `Evaluator` implementation would ever access the raw object, and
> only to convert it to an immutable data structure.
>
> > If the only reason you are trying to do this is performance, then I would
> > appreciate, some benchmarks to reproduce, so I can work with you on
> these.
> > In all the benchmarks that I did internally for embeddings I could remove
> > the cost of the polyglot abstraction almost entirely.
>
> The other motivation is that a direct conversion is much easier to
> implement. I’m not quite sure how to shoehorn a dozen language-internal
> data types carrying data and metadata into `TruffleObject`s, then convert
> them back to their external (i.e., Evaluator) API equivalents. But I’ll
> give it a try.
>
> > BTW.: I have just merged a new PR that makes it more efficient to do many
> > operations with the Value API. [1]
> > For example you can now do
> > context.enter();
> > // perform many operations using the polyglot api
> > context.leave();
>
> What if after calling `context.enter()`, I would execute a node directly,
> instead of using the polyglot API? Would this be enough to get
> `TruffleContext` and time/memory boxing to work?
>
> Thanks,
> Peter