Details on .NET memory management requirements/gotchas about chakra-samples HOT 3 OPEN

Hi @avonwyss . This is the wiki detailing ChakraCore's memory management. I added a small para at the end for .NET.

Specifically, the .NET GC was collecting delegates which had been passed to ChakraCore (in my case through JsCreateFunction and JsSetPromiseContinuationCallback), which made it so that all unit tests were running fine but when running in the application with some memory pressure things started go awry.

The AV problem you mentioned is indeed because .NET GC is not aware of ChakraCore GC references. There were some discussions long ago about how to get around that.

ChakraCore telling me that it was running on the wrong thread

Is a different issue because of ChakraCore's rental threading design.

from chakra-samples.

Hi @liminzhu

Thank you for the quick reaction. I think it would be best to somehow include this into the .NET samples, which is why I posted it here.

Regarding the wrong thread error, in my case it was really caused by the memory corruption; I had locks around every single access to JS context and the problem was intermittent with the AV errors. Also, it did not behave the same with and without debugger (got the wrong thread usually without debugger, and AV with debugger).

Note that pinning is not necessary and not advisable, keeping a Normal GCHandle is entierly sufficient. See also the GCHandleType docs.

from chakra-samples.

I think it would be best to somehow include this into the .NET samples, which is why I posted it here.

Generally agree with your sentiment. Will try to come up with some short code snippet and documentation as said in microsoft/ChakraCore-wiki#5. Meanwhile, feel free to send a PR against Chakra-samples if you're interested in getting a sample online 😄.

Regarding the wrong thread error, in my case it was really caused by the memory corruption; I had locks around every single access to JS context and the problem was intermittent with the AV errors. Also, it did not behave the same with and without debugger (got the wrong thread usually without debugger, and AV with debugger).

Do you have a short repro I can play with? I would love to look more into it.

Note that pinning is not necessary and not advisable, keeping a Normal GCHandle is entierly sufficient. See also the GCHandleType docs.

Yep, I meant extending the lifetime at least till callback/object is no longer needed.

from chakra-samples.