Editor allocator destroyed on compilation

[dense bay]

I'm using AllocatorHelper<RewindableAllocator> in a monobehaviour that has [ExecuteAlways]

It's created in the Awake and destroyed in the OnDestroy. However, when I reload scripts, the allocator is destroyed (the ptr inside the struct becomes null), yet the OnDestroy has not been called. A custom boolean bAllocatorCreated that's in sync with my code remains true.

Beyond the fact that the allocator may be destroyed by the system on compilation, how is it possible that the pointer inside the AllocatorHelper<RewindableAllocator> struct becomes null? It's not a class and not modified by anyone else.

What's the right way to go about using allocators in this way?

I did not find a way to check if the allocator handle inside AllocatorHelper<> is valid, either

[placid condor]

why do you need high performance allocators in edit mode?
does everything work correctly at runtime?
use compile directives to use managed memory in editor

[dense bay]

I was simply looking to share the same code between editor and runtime; it works fine at runtime

it works with jobs and unmanaged memory, so switching to managed memory for in-editor means writing a reasonable chunk of the code twice

one solution is of course to use a global allocator when in the editor and my own when in a build, but I am mostly looking for an explanation

I suppose maybe it's something like that the AllocatorHelper<T> struct stored in the monobehaviour is not (de)serialized when the domain reload happens 🤔

[gritty vessel]

domain reload is different to a unity object destroy, no managed state will survive so as long as it gets re created correctly after this it should be fine.

[midnight carbon]

Are you 100% sure on destroy is not called? Maybe you have several instances of the class?
My understanding is OnDestroy should be called on all unity objects probably from a C++ destructor, so a situation where it's not called at all shouldn't be possible.

[dense bay]

if OnDestroy was called, my boolean should also be false
it's really just like this:

[ExecuteAlways]
class MyMonoBehaviour : MonoBehaviour
{
  void Start() { /* create allocator, set boolean to true */ }
  void OnDestroy() { /* if boolean is true, destroy allocator and set boolean to false */ }
}

and I find myself in a state with the boolean set to true and an AllocatorHelper<RewindableAllocator> pointing to null

I suspect there's something different with the serialization of this structure at the time of script reload

note that domain reload is off in this project

[dense bay]

so, I mean, it's possible OnDestroy IS called but something else is setting this value to null (or not setting it back to its proper value after script reload)

and by "something else" i mean unity's script reloading magic

[gritty vessel]

unitys solution is shit and only works for serialized variables

third party hot reloading solutions work better

[dense bay]

so, you mean, all scripts using ExecuteAlways have issues with non-serializable structures they contain?

that would be a logical explanation I suppose

[gritty vessel]

May be expained by this doc page: https://docs.unity3d.com/6000.0/Documentation/Manual/domain-reloading.html
There are no additional OnDisable or OnEnable calls for scripts marked with the [ExecuteInEditMode] or [ExecuteAlways].

so you would expect instances to keep their state when domain reload is disabled but perhaps some things cannot be avoided when that class changes

[dense bay]

well it would make sense that script recompilation forces a domain reload either way

upon entering and exiting playmode there are no problems

I think I have some sort of understanding now, thanks for your input !