lightning
[Top][All Lists]
Advanced

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

Re: [Lightning] Porting GNU Smalltalk to lightning 2


From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Porting GNU Smalltalk to lightning 2
Date: Sun, 26 Oct 2014 16:14:15 -0200

2014-10-26 15:54 GMT-02:00 Holger Hans Peter Freyther <address@hidden>:
> On Sun, Oct 26, 2014 at 03:17:11PM -0200, Paulo César Pereira de Andrade 
> wrote:
>
>>   I created the reverse hash to simulate the above, after finding that code
>> that did store a nativeCode* could change it to another one (so I could
>> not play smart and store a pointer to a method_entry pointer, and then
>> just dereference the nativeCode pointer when needing it).
>>    Storing the method_entry somewhere in the jit code is possible, could
>> be a jump over the value stored (ugly), a function in the jit that would
>> return the method_entry associated with it (complicated), so, a
>> naive/simple solution for now is the reverse hash table. But other
>> kinds of optimizations could be done.
>
> Ah thanks for the explanation. Okay we have the start of the code pointer
> and we want to find the method_entry it refers to. I know you mentioned it
> already but could you re-iterate why we can't have a "reservation" in front
> of the native code generated by lightning?
>
>
>  jit_pointer_t
> -_jit_emit(jit_state_t *_jit)
> +_jit_emit(jit_state_t *_jit, size_t offset )
>  {
>      jit_pointer_t       code;
>      jit_node_t         *node;
> @@ -1859,10 +1859,11 @@ _jit_emit(jit_state_t *_jit)
>  #if defined(__sgi)
>         mmap_fd = open("/dev/zero", O_RDWR);
>  #endif
> -       _jit->code.ptr = mmap(NULL, _jit->code.length,
> +       _jit->code.ptr = mmap(NULL, _jit->code.length + offset,
>                               PROT_EXEC | PROT_READ | PROT_WRITE,
>                               MAP_PRIVATE | MAP_ANON, mmap_fd, 0);
>         assert(_jit->code.ptr != MAP_FAILED);
> +       _jit->code.ptr += offset;
>      }
>      _jitc->code.end = _jit->code.ptr + _jit->code.length -
>         jit_get_max_instr();
> @@ -1879,6 +1880,7 @@ _jit_emit(jit_state_t *_jit)
>             }
>             if (_jit->user_code)
>                 goto fail;
> +#error "add the offset everywhere"
>
>
> this doesn't look too awful? Does it?

  It is awful :(
  It would not work straight because it would need to start the code
with a jump over the stored method_entry pointer. The longest such
instruction would be 16 bytes in ia64. But, the pointer returned by
jit_emit has been mprotect'ed PROT_READ|PROT_EXEC already...

  The easiest approach is to just use an variably sized structure,
and use jit_set_data, see "7.2 Alternate code buffer" in
http://www.gnu.org/software/lightning/manual/html_node/Customizations.html#Customizations
the example there uses mmap, but you may use malloc'ed
memory, no problem (and see the comments on how you can
even query the likely size of the buffer, and retry unitl it fits...),
just that lightning does leave you on your own about cache sync,
so, with plain memory from malloc, it likely will only work as is
on ix86 or x86_64, and maybe a few others, while some are very
"hard" to sync.
  I may work on a new api to ensure the memory is synch'ed
tough. I hope to have lightning 2.0.6 released when it can
drive GNU Smalltalk :)

Thanks,
Paulo



reply via email to

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