Zoxc

Another fun thing with a single address space is that you can directly link calls to the loaded library code, instead of using a PLT. So the overhead of dynamic linking would be a 60-bit constant instead of whatever relative calls happen to be.

To do lazy loading of libraries we need to patch the constant to refer to the loaded library. You said that the Mill does not support self-modifying code, which does not bode well for such a feature. Is stopping all threads and flushing just the constant from the instruction cache sufficient?

I did not see any details on this in any of the talks. I may have skipped some question sections though.

Can stack barriers be made efficient on the Mill? Sometimes playing with return pointers is useful…

There is a suspicious lack of loadp, which would correspond to Azul’s hardware barrier, is that because it’s patented?

My new plot for statepoints is storep None, which would avoid trashing the cache, but would it trap?

I have rarely seen GCs use tag on pointers, besides Azul Systems’ GCs (which trap based on pointers loaded), can you refer to some literature on this?

I think you may have confused stack barriers with read/write barriers. Stack barriers causes halts if the thread returns past a point on the stack. This is used so that another thread can safely scan the earlier portion of the stack; which will reduce the time the thread has to be halted for stack scanning.

What will the best way to do state points? My current plot is a store to a thread local byte for which can get its permission removed when the thread should be halted. This is not ideal since it would require a 1-cycle delay for the case of a function immediately calling another.