Open LSViana opened 11 months ago
First round of investigations:
For instance, this screenshot demonstrates the scenario (2):
Further investigations will be conducted for other operations.
Second round of investigations:
Doc
instances with DocOptions
that included string
properties would cause an increasing usage of memory until the Dispose()
method of DocOptionsNative
was calledDispose()
method manually and now the memory usage to create Doc
instances with DocOptions
is constant tooThird round of investigations:
Dispose()
on resources, I'm implementing destructors on public
classes exposed by the library.private
or internal
classes or structs shouldn't implement Dispose()
since it's expected that the library, internally, calls Dispose()
correctly wherever it's needed.I think input will also leak memory. e.g. when creating a new collection input a new block of memory is allocated and just the pointer is given to y-crdt. But the pointer is never released. I think a finalizer is needed here.
@LSViana Can we close this?
@SebastianStehle No, the initial work I did here was useful for detecting and fixing memory leaks.
Given the previous discoveries, I believe it's important to check for possible leaks in the pending items too. It's not a complex task, it's more laborious and repetitive, I'll try to do a little bit every day.
In #18, there has been a mention of possible memory leaks in the operations executed through YDotNet.
This issue intends to:
Investigated scenarios (this list is not final):
Doc
Id
Guid
CollectionId
ShouldLoad
AutoLoad
Clone()
andDispose()
Text
string
representationArray
Map
XmlText
XmlElement
Branch
Other fixes:
Delegate
disposal