On Friday, November 1, 2019 at 8:58:13 AM UTC+1, Sokolov Yura wrote:
>
> Don't forget about calling to write barriers.
Of course.
Second update: calling arbitrary Go functions from ARM64 JIT code works too
:)
See https://github.com/cosmos72/gomacro/blob/master/jit/_hide_from_stack
--
You
Don't forget about calling to write barriers.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion
Update:
I found a solution using AMD64 assembly trickery to call arbitrary Go
functions from JIT code, while the JIT code is running on the Go stack and
accessing Go memory.
It is extremely hackish and guaranteed to break as soon as Go function call
ABI changes.
I will try to implement
On 2019-10-24 09:50, Gert wrote:
> This kind of low level is way out of my league but what about
> using https://github.com/tinygo-org/tinygo instead to build your JIT? I only
> know tinygo has no garbage collector at all.
Don't let this stop you getting things done but I would hope that any
This kind of low level is way out of my league but what about using
https://github.com/tinygo-org/tinygo instead to build your JIT? I only know
tinygo has no garbage collector at all.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
Thanks for the idea Rick,
there is one detail I do not understand:
JIT code does not have a stack map **at all**, not even an empty one, thus
(if I remember correctly) calling any Go function from it may trigger a GC
cycle, which will find on the Go stack the "unknown" return address to the
One approach is to maintain a shadow stack holding the pointers in a place
the GC already knows about, like an array allocated in the heap. This can
be done in Go, the language. Dereferences would use a level of indirection.
Perhaps one would pass an index into the array instead of the
