Remove use of handles in interp_exec_method and instead use a reserved stack slot #80197
Conversation
… a reserved slot at the top of the stack
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsRight now every time we enter the interpreter we waste some CPU time allocating a handle, even though the only remaining use of the handle is in the BOX opcodes. This PR instead allocates some space at the top of the stack for a temporary GC-visible object pointer, and then uses that instead of a handle. For my AOT<->interp transition stress test a ~30sec profile run was spending over a second allocating handles and this optimizes that out entirely.
|
|
Is the overhead from HANDLE_FUNCTION_ENTER ()/EXIT () ? Allocating a handle shouldn't be that slow. |
I don't know specifically where the overhead comes from, but the handle_new time in profiles was really significant. It's in a microbenchmark that does tons of transitions, of course, but they show up for json in browser-bench AOT'd as well. It seemed like deferring the handle creation optimized it out in my initial tests, but removing the handles entirely makes sure it's gone. It might be a WASM-specific problem and maybe handles are faster on native? |
|
Looks ok, hopefully it won't break anything. |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
so if it works, hope can backport to release/7.0 |
| @@ -406,7 +406,8 @@ get_context (void) | |||
| context->stack_start = (guchar*)mono_valloc (0, INTERP_STACK_SIZE, MONO_MMAP_READ | MONO_MMAP_WRITE, MONO_MEM_ACCOUNT_INTERP_STACK); | |||
| context->stack_end = context->stack_start + INTERP_STACK_SIZE - INTERP_REDZONE_SIZE; | |||
| context->stack_real_end = context->stack_start + INTERP_STACK_SIZE; | |||
| context->stack_pointer = context->stack_start; | |||
| /* We reserve an object pointer slot at the top of the interp stack to make temp objects visible to GC */ | |||
| context->stack_pointer = context->stack_start + sizeof(MonoObject*); | |||
There was a problem hiding this comment.
We always keep the stack pointer and all interp vars aligned to MINT_STACK_SLOT_SIZE, which is 8 bytes. On 32 bit this breaks alignment. This doesn't appear to be a critical problem, but it would be best to maintain the default alignment.
#80197 accidentally broke interp stack alignment on 32-bit platforms due to pointers being 4 bytes there.
ghost
locked as resolved and limited conversation to collaborators
Right now every time we enter the interpreter we waste some CPU time allocating a handle, even though the only remaining use of the handle is in the BOX opcodes. This PR instead allocates some space at the top of the stack for a temporary GC-visible object pointer, and then uses that instead of a handle. For my AOT<->interp transition stress test a ~30sec profile run was spending over a second allocating handles and this optimizes that out entirely.