lightning
[Top][All Lists]
Advanced

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

Re: [Lightning] Position independence of GNU lightning generated code


From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Position independence of GNU lightning generated code
Date: Tue, 31 May 2016 12:41:33 -0300

2016-05-26 5:39 GMT-03:00 Marc Nieper-Wißkirchen <address@hidden>:
> Thanks for the answer and please excuse my late reply...
>
>>
>> > is the code emitted by `jit_emit` guaranteed to be position independent?
>> > In
>> > other words, if I use an alternate code buffer as in 7.2 of the manual
>> > and
>> > later move that code buffer to a different address (say, by a copying
>> > garbage collector to reduce heap fragmentation), will my code still be
>> > working?
>>
>>   It is very unlikely to work as most non conditional jumps are
>> implemented
>> as a jump to an absolute address. On all ports conditional jumps are
>> implemented as relative jumps, but they may vary in maximum jump
>> distance, and generate an assertion if the target is too far.
>>
>>   Note that code buffers are allocated with mmap, should be at least one
>> page, and are mprotect'ed readonly and executable. So, if you allocate
>> your own code buffer, it should be used only by a very small trampoline,
>> and there may be issues with cache coherence in some architectures.
>
>
> So a copying garbage collector for jit'ed code seems to be too much of a
> hassle.

  There is also temporary memory used during jit generation. You can use
jit_set_memory_functions (works almost like the gmp counterpart, but
assumes memory allocation also zeroes the returned memory) to prevent
any malloc call, but pointers are still hidden, so a copying gc might need
to know internals, if gc is triggered during jit generation.

> But I could use a non-copying garbage collector for jit'ed code if I provide
> alternate code buffers, do I? As soon as I know that emitted code is not
> used anymore, I can safely overwrite is with another call to jit_emit, can
> I?

  Yes, it will work. But to make sure things would work on all platforms, you
should mprotect(..., PROT_READ | PROT_WRITE) before caling jit_emit,
and mprotect(..., PROT_READ | PROT_EXEC) after it. The memory should
also be page aligned, and getting it from mmap is usually the best way.
Stack memory is unlikely to work on all environments, due to non executable
stacks.

> Marc

Thanks,
Paulo



reply via email to

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