nethermind icon indicating copy to clipboard operation
nethermind copied to clipboard

Handle deep EVM call stack using separate thread

Open chfast opened this issue 6 years ago • 6 comments

In relation to the discussion about supporting EVMC, I did small research on the issue of causing native stack overflow when handling EVM call stack naively.

What you can do is adapt a trick Aleth is using. At some EVM call depth height (e.g. 100, the number must be figured out experimentally) you offload execution to a dedicated thread. The thread will have new system stack space and you can specify the size of this stack in C# API. The execution is still sequential - we have to wait for the new thread to finish.

What would be even better is to use coroutines or filbers. These also need to create a separate stack space but this can be implement in a library without the need of creating a thread (this requires asking OS for help). However, to my knowledge C# do not support these out-of-the-box.

Aleth code: https://github.com/ethereum/aleth/blob/master/libethereum/ExtVM.cpp#L34-L57.

chfast avatar Nov 20 '19 08:11 chfast

hi @chfast not sure what you mean here? is that some issue with EVMC that would need to be handled specifically just to be able to support it?

we do not have a call stack per se - we have an iterative and not recursive approach

tkstanczak avatar Nov 22 '19 10:11 tkstanczak

I don't think you will be able to support EVMC VMs with iterative approach.

This was mostly a brain dump. But this is a way to have recursive approach without exhausting system stack.

chfast avatar Nov 22 '19 11:11 chfast

Controversial. I would prefer the EVMC VM to be able to execute everything by just being injected an interface to state, executioin env and tx. Why does it need to impose some requirements on how the Nethermind VM is designed?

tkstanczak avatar Nov 26 '19 12:11 tkstanczak

@tkstanczak is it still valid?

dceleda avatar Aug 31 '22 18:08 dceleda

@tkstanczak Is it still something valid? Maybe we can check if this is something which can improve perf in any way? But feels like something tricky.

cc @benaadams

kamilchodola avatar Jun 03 '24 13:06 kamilchodola

Are many ways of doing this in .NET, can easily offload to seperate "fiber" by implementing the IThreadPoolWorkItem and queuing to threadpool with ThreadPool.UnsafeQueueUserWorkItem; however there very many other ways of doing this e.g. Task.Run etc

Not sure is anything actionable in this issue though?

benaadams avatar Jun 03 '24 23:06 benaadams