Thanks that was helpful. I've noticed that Safepoints are often chosen to be return points from a function call (fallthrough of bx). Hence I thought e.g. a return parameter (I am not sure of the ABI that the V8 JIT chooses) might live in a register. So basically that's not the case and all state will be in memory and nothing "lives" in registers at this point?
On Monday, June 2, 2014 12:55:51 PM UTC-7, Hendrik Greving 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. So in which cases is code actually getting > patched (by garbage collection), e.g. is code getting patched with new > pointer literal values? > > 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)? > > Any help, hints, tips, links would be greatly appreciated! (This one here > is a great summary but didn't answer the questions above > http://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection). > > Hendrik Greving > > -- -- v8-dev mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
