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

[Christian Humer]

Hi Jaroslav, Peter,

@Jaroslav:
- As mentioned in a previous email, Value#as(Class) is coming back soon. It
was not immediately migrated from the original API as the original behavior
was underspecified.
- As far as I understand, Peter is not interested in an interface Pojo view
on JavaScript objects. Instead he just wants fast access to language
specific datastructures without any indirections. But it is indeed still
supported.
- Graal-js-archetype is not applicable to Peters problem, as its JS
specific and Peter is developing his own language.

@Peter
> I totally see the usefulness of the `Value` abstraction. My only gripe is
that there is no way to do without it for language-specific use cases.

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.

What do you want to do in particular?


> For the language-specific use cases I have in mind, having *some* way to
get at a language’s internal object representation would be very valuable.
This could take the form of `Value.getRawObject()`, or
`Value.as(MyApiObject)` together with registering a converter from
`MyLangObject` to `MyApiObject`, or sending a custom interop message that
is allowed to return `MyLangObject` unwrapped. Such a language-specific
conversion could certainly take care of handling things like value type
semantics as appropriate.

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 boundaries between host and guest are not strong, and might expose
Truffle partial evaluation semantics to the host. (as mentioned previously)
- It breaks the abstraction of the language implementation. (you make your
embeddings dependent on language implementation specific API)

So in order for a language to properly expose APIs they need to manually
enter/leave a context and have proper partial evaluation boundaries. I know
that is not really a problem for you, but for us its important that the
language implementation is treated as untrusted code. We could expose an
API that allows languages to safely expose such objects, but it would
likely be very complicated and it would restrict us even more to evolve the
platform.

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.

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();

This is more efficient if you need to access your guest language object
many times (iterating an array).
We've also done some internal efficiency enhancements such that a call to
Value#executeVoid() is as fast as CallTarget#call().

[1]
https://github.com/oracle/graal/commit/471468b55f44da291d18ca35ee9f64095cb752d8

Cheers,

- Christian Humer




On Mon, Jan 15, 2018 at 11:09 AM Jaroslav Tulach <jaroslav.tulach at oracle.com>
wrote:

> Hello Peter,
> thanks for your interest in Truffle polyglot programming.
>
> On sobota 13. ledna 2018 13:30:35 CET Peter Niederwieser wrote:
> > > There are certain aspects in some of our languages that cannot be
> > > represented with core JDK classes. This is where the Value API comes
> in.
> > I totally see the usefulness of the `Value` abstraction. My only gripe is
> > that there is no way to do without it for language-specific use cases.
>
> While `Value` abstraction may be useful in certain situations, there is a
> lot
> of use-cases already supported by Truffle/Java polyglot API that can do
> without
> it. The goal of my design in 2015 and 2016 was to allow POJO interfaces to
> smoothly interact with Truffle languages. As far as I can tell my ideas are
> still supported and could be exactly what you are looking for.
>
> Me and Michael had written a tutorial that shows the capabilities:
>
> http://www.graalvm.org/truffle/javadoc/com/oracle/truffle/tutorial/embedding/
> package-summary.html
> <http://www.graalvm.org/truffle/javadoc/com/oracle/truffle/tutorial/embedding/package-summary.html>
> please take a look at section like "Access a JavaScript class", "Access a
> JavaScript Array", "Access a JavaScript JSON structure", etc.
>
> All these ideas are used in graal-js-archetype, see
> https://github.com/graalvm/graal-js-archetype#readme for explanation and
> instructiosn how to get started. The archetype performs all the JavaScript/
> Ruby/R/Java interop and it does it all without the `Value` class. Give it a
> try to get better understanding of the existing POJO-based interop
> possibilities.
>
> I believe these two examples show you can do without the `Value` class[1].
> Give it a try. If you have some questions about graal-js-archetype or the
> tutorial, let me know. I'll be glad to reveal the proper way to POJO-like
> Truffle interop.
> -jt
>
> [1] In fact the `Value` approach stays in the way as it (in contrary to
> original `PolyglotEngine.Value` class) doesn't offer `T as(Class<T>)`
> conversion function. However (as the graal-js-archetype shows) this
> limitation
> can be overcome. Good luck.
>
>