refactor: explicit invalidations for native and cpp

[tjzel]

Summary

This pull requests refactors memory management of Worklets and Reanimated.

Basically, since Reanimated can obtain WorkletsModuleProxy and the Worklet Runtimes as shared pointers, it has to release them explicitly during the invalidation stage of Native Modules. Releasing them later on (e.g. via deconstructors) might lead into issues and crashes.

Ideally we'd instead use some different solution here than shared pointers, but it can wait as it's not mandatory at the moment and could be a significant refactor.

Fixes:

• iOS crash on reload
• Android crash on SingleInstanceChecker during third reload

Test plan

• 0.76 iOS/Android Fabric works
• 0.76 iOS/Android Paper works
• 0.75 iOS/Android Fabric works
• 0.75 iOS/Android Paper works
• 0.74 iOS/Android Fabric works
• 0.74 iOS/Android Paper works

[tjzel]

Turns out we don't need to keep the reference to Java part of WorkletsModule in cpp.

[tomekzaw]

Does it still have to be a HybridClass or can we convert it back to JavaClass or something?

[tjzel]

When cleaning during invalidation stage, it shouldn't be possible for two instances to exist at the same time.

[tomekzaw]

Why not just instanceCount_ == 0?

[tomekzaw]

The changes look good to me, I left some remarks in the comments. Two more general questions:

1. Why do we need a separate invalidate method? Why can't we just clear the pointers in C++ destructors like we used to do?
2. Once invalidate method is called, shall we add some assertions to prevent us from calling any methods of an invalidated object?
3. Why can't we just use weak pointers to store WorkletsModule in ReanimatedModule? This way there's no strong link between those two.

[tomekzaw]

Why not just instanceCount_ == 0?

[tomekzaw]

This change looks weird, do we really need WorkletsModule to be a Hybrid class if we don't use jThis here in makeCxxInstance?

[tomekzaw]

Let's add a newline here since [super invalidate]; is unrelated to the comment above.

Suggested change

	// We have to destroy extra runtimes when invalidate is called. If we clean
	// it up later instead there's a chance the runtime will retain references
	// to invalidated memory and will crash on destruction.
	workletsModuleProxy_.reset();
	[super invalidate];
	// We have to destroy extra runtimes when invalidate is called. If we clean
	// it up later instead there's a chance the runtime will retain references
	// to invalidated memory and will crash on destruction.
	workletsModuleProxy_.reset();
	[super invalidate];

[tomekzaw]

Let's add a newline here as well

Suggested change

	// We have to destroy extra runtimes when invalidate is called. If we clean
	// it up later instead there's a chance the runtime will retain references
	// to invalidated memory and will crash on its destruction.
	invalidateCpp();
	mAndroidUIScheduler.deactivate();
	// We have to destroy extra runtimes when invalidate is called. If we clean
	// it up later instead there's a chance the runtime will retain references
	// to invalidated memory and will crash on its destruction.
	invalidateCpp();
	mAndroidUIScheduler.deactivate();

[tomekzaw]

If possible, let's pass the runtime as a reference instead of a pointer, i.e. jsi::Runtime &.

[tomekzaw]

If possible, let's store runtime as a reference.

Suggested change

	jsi::Runtime *rnRuntime_;
	jsi::Runtime &rnRuntime_;

[tomekzaw]

Does it still have to be a HybridClass or can we convert it back to JavaClass or something?

[piaskowyk]

Could you elaborate more on why performing cleanup in the C++ destructor is considered too late? This isn't entirely clear to me, but it seems to be important.