Opened 7 years ago
Last modified 3 years ago
#4785 new defect
Memory is never given back
| Reported by: | ceraolo | Owned by: | somebody |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | *unknown* | Version: | v1.13.0-dev-nightly |
| Keywords: | Cc: |
Description (last modified by ceraolo)
I've seen that OM (at least when used through OMEdit), never gives back memory. I understand that it uses Garbage collector, but AFAIK, at least periodically, if large amounts of memory are not allocated anymore, they should be sent back to the OS to give other processes a chance to exploit.
Steps to reproduce (OM 1.13 dev 380, win 64 bit):
1) launch OMEdit Now Task manager reports 450 MB as allocated to OMEdit.
2) load Buildings library (5.0.0: should be the latest) and double-click on Air.Systems.SingleZone.Vav.ChillerDXHeatingEconomizer
Memory reaches 3.65 GB
3) unload Buildings library. The loaded memory stays above 3.6 GB whatever you do, except closing OMEdit.
BTW, the memory used seems to be too large: Dymola for the same case uses just 235 MB total. But this is another story (see discussion on ticket #4755).
Change History (7)
comment:1 Changed 7 years ago by ceraolo
- Description modified (diff)
comment:2 Changed 7 years ago by sjoelund.se
comment:3 Changed 6 years ago by casella
- Milestone changed from 1.13.0 to 1.14.0
Rescheduled to 1.14.0 after 1.13.0 releasee
comment:4 Changed 5 years ago by casella
- Milestone changed from 1.14.0 to 1.16.0
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0
comment:5 Changed 4 years ago by casella
- Milestone changed from 1.16.0 to 1.17.0
Retargeted to 1.17.0 after 1.16.0 release
comment:6 Changed 4 years ago by casella
- Milestone changed from 1.17.0 to 1.18.0
Retargeted to 1.18.0 because of 1.17.0 timed release.
comment:7 Changed 3 years ago by casella
- Milestone 1.18.0 deleted
Ticket retargeted after milestone closed
From my testing of this... most memory seems to be reported to be reclaimed by the garbage collector, but some GB+ is not. Possibly due to some caching either in OMEdit or OMC itself. I'll leave this open until I figure out where that memory is used.
I think we should have some way in OMEdit (perhaps in Help->XXX) that displays some useful internal information such as the amount of free memory out of the currently allocated memory since I crashed OMEdit a bit when trying to get these statistics. This could be done without an API call, but perhaps it would also be useful to have in the scripting API. Perhaps we should also have a scripting API that clears all caches in OMC that you could call from OMEdit...
Note that OMEdit itself also caches a lot of data for drawing the icons which might not be released. @adeas31, how is this handled?