[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Memory Allocation on Mac OS X

From: Paolo Bonzini
Subject: Re: [Lightning] Memory Allocation on Mac OS X
Date: Tue, 28 Sep 2010 08:49:19 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.3

On 09/28/2010 06:52 AM, Paulo César Pereira de Andrade wrote:
2. Knowing the range from two jit_prolog() calls, it can figure the range of a
   function. Could even know about dead code, but probably better to not try
   to be too much smart about jumps and jump targets, just slightly smart :-)

I'd rather leave maximum flexibility to the user of lightning. For example in GNU Smalltalk I'm not using the stack at all. There is a trampoline using jit_prolog, but all compiled methods have their entry point after jit_prolog's expansion (they jump from method to method storing the return addresses in heap-allocated frames). This assumes that jit_prolog emits the same code for all of its occurrences.

3. Most important, this linked list should have information about non relative
   labels, so that it could even reallocate the buffer and adjust offsets. This 
   tricky, because to have it to work transparently, it would need to modify the
   api, that is, instead of having a label as a "jit_insn *", it would need 
   more like:
     jit_movi_p(&my_label, r0, pointer);
     jit_bner_i(&my_other_label, r0, 0);
   otherwise, if it resizes the buffer, with either allocate a new one and copy
   contents, or try to extend with realloc or mremap, it may need to adjust
   "pending" labels.

I'm just throwing away the compiled code and restarting from scratch currently if I detect an overflow.

   Just some ideas... This would also make it easier/safer to use the change
I did to adjust the stack alignment in i386/x86_64 by patching the immediate
to adjust %esp in the jit_prolog call, as it could figure out what routine it 
jump to, but forward jumps to another function would still be tricky; the 
is that if it jumps to another function, and call another from there, if it 
the stack adjustment due to building a large frame, it will patch the adjustment
of the wrong function, same if it calls jit_allocai to have some %ebp relative
buffer, like is done for x87/sse conversion (but this one is mostly for testing,
maybe should always allocate the first 8 stack bytes for it, or just push/pop

Yes, these are the problems I was hinting at. The root idea is that lightning _is_ an assembler, so it is hard to define what the user can and cannot do. The instances of "undefined behavior" should be very limited, and JIT compilers can use many tricks that lightning should support.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]