Re: Managing the JIT

"BGB / cr88192" <>
Sat, 8 Aug 2009 12:11:02 -0700

          From comp.compilers

Related articles
[8 earlier articles]
Re: Managing the JIT (BGB / cr88192) (2009-07-30)
Re: Managing the JIT (Armel) (2009-07-31)
Re: Managing the JIT (Barry Kelly) (2009-08-01)
Re: Managing the JIT (BGB / cr88192) (2009-08-02)
Re: Managing the JIT (BGB / cr88192) (2009-08-02)
Re: Managing the JIT (Aleksey Demakov) (2009-08-07)
Re: Managing the JIT (BGB / cr88192) (2009-08-08)
| List of all articles for this month |

From: "BGB / cr88192" <>
Newsgroups: comp.compilers
Date: Sat, 8 Aug 2009 12:11:02 -0700
References: 09-07-079 09-07-086 09-07-087 09-08-015
Keywords: incremental
Posted-Date: 09 Aug 2009 22:10:51 EDT

"Aleksey Demakov" <> wrote in message
> Usually a JIT compiles functions on demand.
> That is when it sees a call to a function that has not been compiled
> yet it generates a "trampoline" for this function. The trampoline is a
> small bit of generic code that does these things:
> 1) invokes the JIT compiler for the function in question;
> 2) upon compilation jumps to the newly generated binary code in RAM;
> 3) patches the call site so that all further calls go
> directly to the binary code.
> This way the function is compiled the first time it needs to be
> executed. And if a function is never executed it never compiled and
> JIT even never looks at its source/byte code.


this has been one of the main reasons in the past I had refrained from
calling my compiler a JIT:
it does not exactly "JIT" things in the above sense.

rather, it typically behaved more like a traditional compiler, essentially
forcing through big chunks of source code, compiling them, and linking them
into the image.

a JIT-style strategy has been floating in my head as of late, in particular
for the development of a "generic bytecode" + trampolines and demand

however, for the time being I have decided to "pause" my compiler/VM related
efforts in an attempt to pursue goals related to other parts of my project.

I am now thinking that, for me at least, trying to go the C++/Java/C# route
is just too much work for too little gain... (after all, I already have a C

implementing a C compiler "opens a can of worms", but trying for C++
"unleashes the devil", as it would seem...

so, I may change directions, and instead redirect my efforts into making a
"C-level JavaScript", namely, a JavaScript like language which has fairly
direct access to the C based world (although, likely only a subset of the

in particular:
JavaScript style syntax;
dynamic types (actually, the compiler would likely use static-typing
internally, where dynamic case is considered as a "special" case of static

can access C functions (or, at least those operating within certain
would have a partial (as in, very limited) pointer system;

so, it would relate to C similar to how C relates to assembler:
C has its own confined semantics and typesystem (vs ASM);
however, C can call freely into ASM, so long as the ASM obeys the C ABI;
and, ASM can be used to write all this stuff which can't really be written
in C.

this way, the language can be JS-like, but much of the implementation and
lower-levels would be C.

conviniently, this would also get around a lot of the "problem areas"
related to "going dynamic" in C-family languages (namely, the complexity
spikes, and one ends up with a non-orthogonal mess).

however, I have enough experience to know that, dynamic languages, by
themselves, are not particularly complicated (internally, getting C compiled
is far more scary IME...).

the major reason being that, for C, everything has to be "exact" (the
compiler can't be like "well, I have no idea what the types are here, just
do something generic..."), whereas with a dynamic language, one can get by
primarily generating code via guestimation and oportunism (or, at least,
this is how my last dynamic-language JIT worked...).


yep, interesting, will look...

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.