ExtendedWeakReference data on flash is deleted after calling GC

[techcap]

ExtendedWeakReference data is loaded from flash on initial time(CLR_RT_Persistence_Manager::Initialize()) whether we use ExtendedWeakReference or not, and marked as WR_Restored.

On CLR_RT_GarbageCollector::CheckMemoryPressure(), if memory is pressured, it deletes all WR_Restored objects.

So finally ExtendedWeakReference data is deleted after calling GC.

Is it intended operation?

[doingnz]

I have not looked that the specifics you mention. From my experience, the Week references are not deleted when the GC is called. We call the GC prior to performing a key measurement in our system, so we would notice real quick if they were deleted.

To ensure the weak references are actually save in the first instance, it is necessary in my experience to reboot NetMF to actually commit to flash. This has been the case from NetMF v4.1 and still appears necessary in NetMF 4.4.

Try reboot netMF after you update your ExtendedWeakReferences. They should be available when netmf starts up again.

This is not pretty from an end user perspective as our application must reboot after settings are changed when they are saved as ExtendedWeakReferences.

To overcome this, I implemented a custom interop assembly that calls into the existing firmware C/C++ support for the settings block used by MFDeploy/NETMF to save IP address etc. Nice simple named blocks of storage. This works, but I have not tested extensively. Specifically there is a challenge if the settings are changed "often" as that block of flash will be filled and would need to be erased and all the other settings copied back into the fresh flash. It would be nicer if there ware logic to have bank A and Bank B to save clean copy to new block before erasing "full' block. The current API also require the caller to know the exact length when reading the block. This is unnecessary as the named block knows how big it is and puts an unnecessary restriction on what can be stored. An advantage of the Settings block is that the named blocks are accessible to MFDeploy. It is easy to extend MFDeploy to read/write custom named blocks too.

[techcap]

When I do with 429 and external ram, there was no memory pressure. So I thought ExtendedWeakReference worked properly. But After changing to 412 without external ram, the problem occurred. So I commented out the code.

        //TINYCLR_FOREACH_NODE_BACKWARD(CLR_RT_HeapBlock_WeakReference,weak,g_CLR_RT_ExecutionEngine.m_weakReferences)
        //{
        //    if(weak->m_identity.m_flags & CLR_RT_HeapBlock_WeakReference::WR_Restored)
        //    {
        //        if(weak->m_targetSerialized)
        //        {
        //            fExit = true;

        //            g_CLR_RT_Persistence_Manager.InvalidateEntry( weak );
        //        }
        //    }
        //}
        //TINYCLR_FOREACH_NODE_BACKWARD_END();