thomaswue

Great to hear! The project will continue to evolve and bring innovation for the developer community.

What are the constraints on station names - i.e. min length, max length, maximum number of different names?

This compilation step is only required once when you release your tool. The resulting binary is then providing fast startup and low memory footprint whenever users invoke your tool. So, yes, it is a real win if your tool gets used more than once.

Yes. Sulong assumes that at least the LLVM bitcode including debug information is available. It does not work with third party machine code binaries where no source information is available.

Yes, this is an excellent description.

The default when running static languages like C++ or Rust or Go via Sulong is to stick to the memory layout chosen by the programmer. There is no conversion to typical JVM memory layouts. Nor does running on the JVM has major restrictions for the framework (we are working on a version that does not run on the JVM in the SubstrateVM project). What Graal+Truffle allows is for library writers and language designers to invent new representations without any restrictions on the layout and have them interact with the rest of the system. We want programmers to use the best language for the task. And even combine multiple languages within one program. Foreign objects can be passed around freely as parameters and local variables, but there are restrictions when building combined data structures - e.g., if you have a highly optimized native data structure, it is not possible to install a pointer to a JavaScript object in it without performance loss.

It works without common memory layout between Truffle languages. It even simplifies the ability to use diverse physical memory layouts within the same language. The programmer specifies the logical layout based on the semantics of a language. The runtime decides how to map this logical layout onto the physical hardware. It can take into account the trade-offs the programmer decided to choose.

The idea of Truffle language interoperability is to avoid switching the representation at the language boundary. Objects carry their type information with them that includes the semantics on how to access their properties. This also allows Truffle to fake up the existence of an object without actually performing allocations (e.g., a table in raw buffer format can be interpreted as an array of objects). This clear separation of logical and physical layout enables efficient data representation in the context of higher level languages that typically suffer from pointer chasing and object header overheads.

Agreed that this is only research prototype with significant limitations at the moment. Dynamic changes to the graph should however be something in particular a dynamic optimization framework like Truffle can cope with.

The Graal OpenJDK project is available open source with a GPL license (http://openjdk.java.net/projects/graal/). The Truffle API includes a Classpath exception allowing language implementors free choice of license (http://mail.openjdk.java.net/pipermail/graal-dev/2013-August...). We welcome anybody who wants to work with us on moving language implementations co-existing on a single platform forward.