SOMns icon indicating copy to clipboard operation
SOMns copied to clipboard

Async stack trace structure (from dev)

Open clementbera opened this issue 6 years ago • 3 comments

Version rebased on dev branch for SMarr review.

So far basic synchronous on asynchronous benchmark are working with the different settings enabled. With the settings disabled everything should keep working too. Still need to work on printing the stack with the different settings enabled or not.

Three additional settings: --async_stack_traces_structure: enables the shadow stack entry, allowing to recreate the stack across asynchronous calls. --async_stack_traces_method_cache: enables per method cache to CachedDispatchNode or LexicallyBoundDispatchNode, avoiding to create shadow stack entry if a method is called from a single dispatch node. --async_stack_traces_inline_cache: enables per shadow stack entry creation site cache, avoiding to create repeatedly the same shadow stack entry in loops, the first few times a loop is created.

async_stack_traces_structure has to be enabled for the other ones to change anything. The other 2 settings can be enabled separately or together.

clementbera avatar Jan 22 '19 13:01 clementbera

@clementbera thanks for all the work so far. Before I continue trying to understand all the changes, what's the status with the tests? Any estimate on whether this is a fundamental issue or just about working through the various scattered small issues here and there?

smarr avatar Jan 28 '19 10:01 smarr

Before we added our change, there was already a try catch getting invalid assumption and replacing the node by the next in cache. This happened when guard.entryMatches raised the invalid assumption exception.

With new code this led to an infinite loop since the node was replaced with another node with the exact same guard.

I added a branch in the catch to check if the problem came from the guard or the stillUniqueCaller assumption. Depending on where it comes from, the problem is dealt with differently. In both cases, it leads in the end to a stable ast with a fast path.

clementbera avatar Jan 31 '19 15:01 clementbera

@clementbera ok, thanks for the explanation!

smarr avatar Jan 31 '19 15:01 smarr

This PR is out of date.

A new one may be opened based on the current branch derived from Carmen's version, which is based on Clement's code: https://github.com/smarr/SOMns/tree/ct/async-stack-traces

smarr avatar Oct 14 '22 16:10 smarr