Re: LPEG on Solaris

[Heinrich Hartmann <heinrich@...>]

Dear Roberto et. al.

thanks for your comments!

I understand that a ~50% performance penalty is not acceptable.

* We have tried to avoid repeated allocations by using a single global
allocation [1].
  However, this is not working, yet.

* As for 'fixing' luajit. Your approaches sound reasonable, Roberto --
but I am not deep
  enough into luajit that I would be able to make a qualified
assessment or fix it myself.
  I'll reach out to Mike Pall. Maybe he can comment on this.

* Assuming that the above approaches are not viable. How about
introducing a compiler flag
  e.g. `-DNO_ONSTACK_LIGHTUSERDATA` that explicitly enables the calloc-patch
  and causes the performance penalty?

Best regards,
Heinrich

[1] https://github.com/HeinrichHartmann/lpeg/commit/480c2c2cffc39d513cac90019e40410e7349d471

On Thu, Jun 2, 2016 at 9:49 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> On illumos and similar systems...
>>
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> int main() {
>>   char foo[32];
>>   printf("%llx\n", (uintptr_t)foo);
>>   return 0;
>> }
>>
>> will result in a perfectly reasonable pointer of:
>>
>> fffffd7fffdffb80
>>
>> this is what makes it problematic.
>
> Either I don't understand what you are saying or you did not understand
> what I said.
>
> It does not matter the value of '&foo'. As long as it differ by at
> most 2^30 from some base stack address (easily saved on start up),
> all LuaJIT has to store is that 2^30 offset plus one bit to tell
> that the address refers to the stack (and therefore must be added
> to that base stack address when queried).
>
> -- Roberto
>



-- 
Dr. Heinrich Hartmann
Stefan-George Ring 41
81929 München

Mobile: +49 1525 363 8134
Landline: +49 89 95928493
Web: heinrichhartmann.com
Twitter: @HeinrichHartman