Re: [omr-dev] Callback based IL generation

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

I neglected to include another important
factor in dynamic systems, which is inlining: unless the JIT has a way
to "ask" for the IL for a method being considered for inlining,
you'll limit the inliner's ability to explore the hot parts of the call
graph below the method being compiled.

I think the callback model is much more
effective for the inliner than the "provide everything that might
be needed up front" model.

Mark Stoodley		8200 Warden Avenue
Senior Software Developer		Markham, L6G 1C7
IBM Runtime Technologies		Canada
Phone:	+1-905-413-5831
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:      
 "Mark Stoodley"
<mstoodle@xxxxxxxxxx>
To:      
 omr developer discussions
<omr-dev@xxxxxxxxxxx>
Date:      
 2018/06/04 10:02 AM
Subject:    
   Re: [omr-dev]
Callback based IL generation
Sent by:    
   omr-dev-bounces@xxxxxxxxxxx

---

Thanks for the feedback!

So, rather than creating a MethodBuilder object and passing that to compileMethodBuilder
which will call that object's buildIL() function, you would prefer to build
the IL yourself and then call compile() on it?

That is a model we're working towards enabling via the record/replay function
I've mentioned a few times in the issues.

"Unfortunately", a dynamic JIT infrastructure does not have as
much motivation to be able to record/replay its intermediate language,
and so we have never made it all the way to a fully persistable IL format
(like other dynamic compilers like Hotspot, but unlike compiles like LLVM).
There is an ongoing effort to persist the IL using a textual format reminiscent
of s-expressions that's currently being used to be able to create precise
IL trees for testing the code generators. You can see this stuff in compiler/fvtest/compilertriltest
. Given the ongoing evolution of the compiler IL and its complexity due
to density concerns (it is a dynamic compiler, after all :) ), it's not
an easy task to build a full persistence layer that can evolve easily with
the IL. But we're trying. The performance of the JIT itself does not improve
with a persistence layer, but the maintenance of the IL structures can
become more tedious, so the trade-off here needs careful attention to balance
concerns appropriately.

There are some other important factors here as well. Since the IL changes
throughout the compilation, having the JIT be in control of the IL allocations
allows it to be more efficient at managing memory (using pools, regions,
or even just bulk de-allocate at the end of the compilation). If the IL
is pre-allocated (i.e. provided as input), then managing memory makes an
already complicated subject that much more complicated. 

The first step of compilation is considered "generate IL for the thing
you want to compile". So the most natural fit is a callback based
approach. In many dynamic languages, since the input conditions change
over time as "classes" are loaded/changed/unloaded, generating
the IL on demand when you want to compile the method probably allows you
to generate better IL which means better code.

Nonetheless, for other reasons, we're looking at record/replay for JitBuilder
to log calls to JitBuilder classes and "replay" them during the
callback to generate the necessary IL during compilation, for scenarios
where that makes the most sense. This recording capability basically enables
a kind of generic "bytecode" that's designed specifically to
be used to generate IL (i.e. it is not an executable format like most bytecode
definitions).

Hope that helps!

Mark Stoodley		8200 Warden Avenue
Senior Software Developer		Markham, L6G 1C7
IBM Runtime Technologies		Canada
Phone:	+1-905-413-5831
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:        Dibyendu
Majumdar <mobile@xxxxxxxxxxxxxxx>
To:        omr
developer discussions <omr-dev@xxxxxxxxxxx>
Date:        2018/06/03
05:05 PM
Subject:        [omr-dev]
Callback based IL generation
Sent by:        omr-dev-bounces@xxxxxxxxxxx

---

Hi,

I initially thought the callback based approach to IL code generation
was just an API artifact. But it seems to be quite deep - i.e. the
compiler invokes it at its base level to get IL generated by the
front-end. I wish this was not the case - and there was a way to
present fully formed IL to the compiler - but my guess is that this is
not possible without major refactoring.

A callback based approach is not only hard to model as an API - but
also unnecessary complexity in a JIT. After all the client is using
the API to generate code in the first place!

Regards
Dibyendu
_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev



_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev