Separating parsing and execution

[Jaroslav Tulach]

Dne Po 3. srpna 2015 13:22:37, Benoit Daloze napsal(a):
> On Fri, Jul 31, 2015 at 7:35 PM, Jaroslav Tulach <jaroslav.tulach at oracle.com
> > wrote:
> > 
> > Dear Truffle language writers,
> > have you ever thought about what Truffle does when the same source code is
> > executed multiple times in the same JVM? Did you wonder if that is
> > effective?
> > Well, it wasn't, but today we are making the first step to improve it. We
> > now
> > ask you to parse the Source first and delay execution for later:
> > 
> > http://lafo.ssw.uni-linz.ac.at/hg/truffle/rev/e7c2d36daf72#l5.21
> > 
> > How does that help? Well, we can cache the CallTarget (and its ASTs) and
> > if
> > the same file gets executed twice, we can re-use them. There is just one
> > catch: you cannot store single execution data in your nodes persistently.
> > We
> > are still working on the best way to store/obtain them. Right now there is
> > 
> > http://lafo.ssw.uni-linz.ac.at/hg/truffle/rev/e7c2d36daf72#l5.47
> > 
> > but it may not be the best solution. It is likely to change a bit.
> 
> Where should we store the local execution state then?
> For instance, execution profiles?

Chris mentioned execution profiles, so I guess the answer is yes (but I have 
no idea what execution profile is). The general idea is that if your languages 
is running in a single threaded environment, it will be as fast as now. Once 
it starts to be used from many threads, it will deoptimize a bit, but share 
the code among all the callers.

> Also, of course the nodes will specialize and create new nodes, is that a
> special form of allowed state?
> 
> The current strategy to keep a never-run copy of the AST
> and create the CallTarget on a copy of that AST when needed seems to be
> much easier (but of course the compilation results are not shared).

Yes, the current state is "easier", but not optimal. My understanding is that 
we should focus on sharing of the code between multiple execution as that is 
going to help us scale.
-jt