On 2 June 2014 20:55, Hendrik Greving <hendrik.greving....@gmail.com> wrote:
> Whenever V8 has to flush the ICache on ARM, this is due to self-modifying > code. I understand this e.g. happens when we patch return points to > optimized code with calls to de-optimization runtime functions. What I > haven't understood is if and when garbage collection actually modifies code > objects (not moving them, if code is moved, that's not SMC, and shouldn't > require to flush the ICache, > It does! On ARM you need to manually ensure coherency of the I and D cache and when the code is moved it is moved as normal data and the I cache may not "see" the move. The same apply when you load a program in memory. SMC is just one case when the caches need syncing. > So in which cases is code actually getting patched (by garbage > collection), e.g. is code getting patched with new pointer literal values? > That can happen too. > Then the second part I'd wanted to understand was where in V8 do we make > sure that when e.g. pointer values are changed (because we moved data on > the heap), that the hardware state in the processor is updated as well > (some pointers might have lived in registers)? > When a GC occurs everything has been written to memory and will be updated. Among other things look for Safepoints. -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
