Re: [Lightning] Porting GNU Smalltalk to lightning 2

[Paulo César Pereira de Andrade]

2014-10-26 14:18 GMT-02:00 Holger Hans Peter Freyther <address@hidden>:
> On Sun, Oct 26, 2014 at 01:27:48PM -0200, Paulo César Pereira de Andrade 
> wrote:
>
>> The incorrect assumption was that a method_cache_entry nativeCode
>> pointer was immutable, what is obviously wrong, and to use a mmap 'ed
>> buffer, need the reverse hash. It is possible to tell lightning 2 where to
>> write jit to, so it could still use a variably sized method_entry structure,
>> but I prefer not, because that means mapping down to the page boundary
>> before and up to after it as executable...
>
> I don't really follow here. In GNU Lightning 1.x and 2.x the cachedIP
> will refer to a native address. The only difference as I can see is the
> method_entry will have the nativeCode allocated/managed by lightning
> now? What prevents us from having a simple forward pointer instead of
> doing a reverse look-up?

  In lightning 1, it was like this:

typedef struct method_entry {
[...]
  int nativeCode[1];
} method_entry;

and in lightning 2 port I changed to:

typedef struct method_entry {
[...]
  void *nativeCode;
  jit_state_t *_jit;
} method_entry;

In lightning 1.x it did map a "native pointer" with this macro:
#define GET_METHOD_ENTRY(nativeCodeStart) ((method_entry *) (           \
  ((char *) nativeCodeStart) - (sizeof(method_entry) - sizeof(int))  ))

  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.

Thanks,
Paulo