Ticket #628 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

Why memory increases when overwriting ImportsAware doc

Reported by: vzholudev Owned by: dmisev
Priority: critical Milestone: Release v1.3.0
Component: System Implementation (SI) Version: all
Keywords: Cc:
Blocked By: Blocking:
Due to close: YYYY/MM/DD Include in GanttChart: no
Dependencies: Due to assign: YYYY/MM/DD

Description

It seems I know the reason. Assume that you added an ImportAware? object to NotationCollector?. Then when creating a new ImportAware? document with the same path, this document is added to NotationCollector? as well. Thus the reference to the old ImportsAware? is retained in the collector, and therefore this object is not freed from memory. => double some of memory for each added ImportsAware? object to the NotationCollector?.

Btw, I didn't have enough time to understand, which from which ImportsAware? will notations be used? From the old one or from the new one? I guess a method public List<Element> collect(Element mobj) throws Exception from NottaionCollector?.java is responsible for that.

Change History

Changed 2 years ago by dmisev

No that's not the problem (but you should remove the old ImportsAware? from the collector). I just realized. Suppose there are two theories with imports to the same theory. With cache overwriting (we should really call this disabled cache..) for both imports the same document is built twice, so they contain the same notations but different Java objects.

As I understood, the user edits some OMDoc and commits to TNTBase. Then only this document needs to be updated, not all the imported ones from it, no?

Changed 2 years ago by dmisev

it will collect from all ImportsAwares? in the collector.

Changed 2 years ago by vzholudev

No that's not the problem (but you should remove the old ImportsAware?? from the collector).

That's the biggest problem since I don't remove source from NotationCollector?, and therefore the hard reference is preserved, hindering the old ImportsAware? object to be freed. That's why we got double amount of memory with double-rendering. You said that I'm supposed to remove it. If yes, how? There are no specific methods to do so, are there? Also providing overwriteCache flag, I supposed that cache is really overwritten, but not doubled. Anyway, it's good that we understood the reason. Or didn't I?

I just realized. Suppose there are two theories with imports to the same theory. With cache overwriting (we should really call this disabled cache..) for both imports the same document is built twice, so they contain the same notations but different Java objects

Yes, very good. It's also a big potential memory leak. Do you know how to fix it?

As I understood, the user edits some OMDoc and commits to TNTBase. Then only this document needs to be updated, not all the imported ones from it, no?

Assume that doc1 and docN have been changed. docN is imported from docN-1, docN-2.... doc1. Then the doc1 and docN have to be updated, and considering that doc1 have implicit links to docN (via multiple HashMaps?, Pairs, ImportsAware? and ImportsAwareTheory?) this link also has to be updated. Therefore we should go through the whole chain from doc1 to docN to update it. Right?

it will collect from all ImportsAwares?? in the collector.

But if there are two equal notations? From the old ImportsAware? and from the new one (assuming that I forgot to delete somehow the old source from the NotationCollector?)

Changed 2 years ago by dmisev

You said that I'm supposed to remove it. If yes, how? There are no specific methods to do so, are there?

yes there are, NotationCollector? is simply a java List. And yes I think we understood it.

Yes, very good. It's also a big potential memory leak. Do you know how to fix it?

When a new ImportsAware? is created, the cache should be overwritten only once for any imported document, so if it is imported again it shouldn't be recreated.

Assume that doc1 and docN have been changed. docN is imported from docN-1, docN-2.... doc1. Then the doc1 and docN have to be updated, and considering that doc1 have implicit links to docN (via multiple HashMaps??, Pairs, ImportsAware?? and ImportsAwareTheory??) this link also has to be updated. Therefore we should go through the whole chain from doc1 to docN to update it. Right?

Maybe I should provide a method to update the content of docN? That way the links will be preserved, and there will be no need to re-traverse the whole chain.

But if there are two equal notations? From the old ImportsAware?? and from the new one (assuming that I forgot to delete somehow the old source from the NotationCollector??)

Usually the one from the ImportsAware? which was first added to the NotationCollector? will win. You can add them in front of the list, so then the new one you added will be chosen.

Changed 2 years ago by vzholudev

yes there are, NotationCollector?? is simply a java List. And yes I think we understood it.

It's a vector I think, but it doesn't matter. But how do I remove the ImportAware? document with the same URI? I can remove the object, but I don't have the link to that object when I want to remove it from NotataionCollector?.

When a new ImportsAware?? is created, the cache should be overwritten only once for any imported document, so if it is imported again it shouldn't be recreated.

Right, that's why I want to add a revnum to uri, but then I should know how to remove previous revisions from the cache. Anyway I'm not going to implement it right away.

Maybe I should provide a method to update the content of docN?

if you have back references (and I saw you did) then why not?

Changed 2 years ago by dmisev

But how do I remove the ImportAware?? document with the same URI? I can remove the object, but I don't have the link to that object when I want to remove it from NotataionCollector??.

You can get the object with ImportsAware.getCachedDocument

if you have back references (and I saw you did) then why not?

Ok then, I'll add ImportsAware ImportsAware.updateOrCreateDocument(Document doc,...) which does this:

  • If doc is already cached it will update its contents by reconstructing imports in case they have changed, and then recollect notations from the theories in it and the newly added imports
  • if it isn't it will create it, add to cache and return.

What do you think? Maybe I should put this functionality (cache, etc) in a separate class ImportsAwareManager?.

Changed 2 years ago by vzholudev

1) Ok, I forgot about getCachedDoc() method. 2) Sounds ok. And yes, a separate class would look nicer imho.

Changed 2 years ago by dmisev

Couple of changes:

  • there's ImportsAwareManager
  • there's no overwriteCache in the constructor, since it's not needed (but there's useTheoryElement instead of it which should be false, so be careful)
  • there's ImportsAwareManager.updateCachedDocument(baseURI, doc) and ImportsAware.update(doc) to update the content of an ImportsAware. Since you're updating the content there's no need to replace anything in the notation collector. This is the only method that would need to be used when some document is modified.

I think the memory/time is quite reduced. Hopefully everything works ok and I'm done with JOMDoc for this month :)

Changed 2 years ago by dmisev

I don't know, what's the status here? Have you checked how this works?

Changed 2 years ago by dmisev

  • status changed from new to closed
  • resolution set to fixed

I'll assume everything is ok, please reopen if problems come up.

Note: See TracTickets for help on using tickets.