Home » Modeling » EMF » Memory disposal during unload()(Intended control for garbage collection)
| Memory disposal during unload() [message #1855896] |
Wed, 09 November 2022 07:08  |
|
It seems that the default implementation of Resource does not free up any memory when it is unloaded(). I wonder if this method is the correct injection point for such controls. I have looked at the EMF book, articles and code but found no definitive answer. Maybe I am misreading the intent of unload all together, and it is only to remove the costly notifiers, rather than the data held by the object itself.
Can anybody point me in the right direction, please?
|
|
| | |
| Re: Memory disposal during unload() [message #1855900 is a reply to message #1855898] |
Wed, 09 November 2022 09:23  |
|
Thank you for your response and sorry for being vague. I am quite familiar with garbage collection and the various classes of weak references available. I was expecting that unload would possibly drop (set null) all the attribute information of an EObject, as this can be reconstructed by loading from the stream, as identifiers should be stable. Depending on the size of these, this could be a relevant savings. Then there would be various degrees of trimming the structure, by tree depth, by use frequency of features, etc.
At the heart of it is that I am simply trying to understand when and why you would unload a resource, other then to disable the notifiers. With the default implementation, as you have stated, unloading uses more memory, not less, as the contents structures use regular references and hence will prevent garbage collection. Even if a client does not hold a reference to any EObject in a reference, the memory is still held, even after an unload.
Or am I missing anything in the memory management here?
[Updated on: Wed, 09 November 2022 09:24] Report message to a moderator |
|
|
| Re: Memory disposal during unload() [message #1855902 is a reply to message #1855900] |
Wed, 09 November 2022 09:36 |
|
w.r.t. Epsilon's use of static features and EMF's global registries, I agree that there is unfortunately not very much detailed control. Part of my exploration of EMF's resource management system is to decide what control facilities would be useful to implement as workflow steps in our build system to properly configure and inspect EMF's mechanisms, and adapt them to Epsilon. For this I need to understand what the intentions of design, capabilities and limits are. I will read up on how CDO has varied the architecture. I can imagine that this would be the missing piece of the puzzle for me.
In case you are wondering why I am after this, here is the
article that describes how we use DevOps toolchains in Agile model-driven engineering.
[Updated on: Wed, 09 November 2022 10:13] Report message to a moderator |
|
| | | |
| Re: Memory disposal during unload() [message #1855926 is a reply to message #1855912] |
Thu, 10 November 2022 05:31 |
|
Hi Ed,
Thanks for having a look. I guess as I stated in earlier discussion, I can run MWE2 from ant, but not the other way around. Note that I am quite aware of it and its role. My working history includes being in charge of the model-driven bus for a large German automotive. And that involved MWE2 and its use. You may find some posts regarding its limitations in automated use if you dig through the history around 2013. I would nod to "far from perfect" as an assessment at least at that point in time. In fact, its usage was so poor that we went around it and wrote things in gradle to achieve reasonable behaviour. W.r.t. EMF not progressing beyond toy applications I guess I am saying that its industry relevance is quite limited and that, in large part, is due to Eclipse's intractability. This extends to EMF transitively. If I propose to use Eclipse as a basis for our work, I do that so we benefit from EMF's positive properties in the Eclipse component context. My developers would much rather I ditch it today and use Epsilon and Gradle only. The thinking I receive in mde net is much the same. So either the joint investment of EMF so far is made to pay, or we can throw it in and rewrite in TypeScript. Which is, by the way, seriously suggested. Use mine (i.e. xText) is not enough. I am very happy for the frame EMF has provided. It and you must be credited for removing the clunk of MOF out of the equation and so it and you succeeded, where JMI failed. Now my view would be to make sure that it becomes an industry engineering solution, rather than a click-click IDE tool or an academic pass time that will be ignored in the trenches. And for that I need reuse, and for that, at this stage, I will accept ant.
Best wishes,
JG
[Updated on: Thu, 10 November 2022 05:34] Report message to a moderator |
|
|
Goto Forum:
Current Time: Thu May 02 13:19:38 GMT 2024
Powered by FUDForum. Page generated in 0.03558 seconds |
] 
Search
Help
Register
Login
Home
