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: Holger Hans Peter Freyther
Subject: Re: [Lightning] Porting GNU Smalltalk to lightning 2
Date: Sun, 26 Oct 2014 22:17:46 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Sun, Oct 26, 2014 at 04:14:15PM -0200, Paulo César Pereira de Andrade wrote:

>   It is awful :(

Yes, specially with R^X.. I see. and I do prefer lightning dealing
with PROT_EXEC, flushing the cache of the CPU, etc.

>   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.

right, it is not where I want to go. The invalidation is very
noticable for interactive workloads (gst-browser compiles a method,
adds it to the method dictionary and then executes it) so I wonder
what other options we have. But I think you are right and the hash
you added is the right way to move forward right now.


>   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 :)

I want to give it a try on ARM as well. Hopefully this week.




reply via email to

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