Skip to main content
GameDev.net gamedev.net

PRO Tired of ads? Read GameDev.net ad-free and help keep the community independent with GameDev Pro — $3/month.

Mission Control - Om has a problem.

Mission Control - Om has a problem.

Aardvajk
Aardvajk
Journal of Aardvajk · · 2 min read
3,294 5

I realised today why JavaScript doesn't have deterministic destruction. Thought I was so smart basing Om around it.

Cycles.

If one object A references an object B and B references A, Om will never release the entities when they go out of scope. Memory leaks.

This is a well enough studied problem to assume there is no available solution. So where does this leave Om?

It is hardly worth turning it into a garbage collected language. That defeats the whole point of the language in the first place.

Equally, it is too easy to accidentally create cycles, especially with long chains of objects or lists, to just say "Don't do this in Om or you leak memory". I would lose all heart in the project then.

So we are in a quandary. Maybe have to toast an interesting project goodbye and move on.

What really hurts is whenever I go online to research this, everyone is describing the approach I have been using for the last few years as naive :)

To be fair, most of the recent work on Om has been copy-pasting code from version 3 into version 4, so in a way it is nice to have a new problem to think about. Toying with the idea of a hybrid system that does strict reference counting unless it (somehow) detects cycles then falls back on asynchronous garbage collection. I see other languages have accepted this. A real shame though. But I'm unlikely to be the first living human to find a better solution, frankly. I'm good enough at what I do to be sure of that much.

Any suggestions from the floor?


[EDIT] It is even worse than I thought, with lists.


var o = [ ];var n = [ o ];o.push(n);When I try to output the state at the end of the program now, we get an infinitely recursive loop going on until Om runs out of stack space.


This is pretty much impossible to detect. Easy enough in a silly example like this, but a general solution just doesn't exist I don't think.


I'm pretty much starting to lean towards just making it a rule that circular references can cause memory leaks or infinite loops and leaving it at that at the moment. Leaves a bad taste in my mouth but I'm not sure what else I can do.

Discussion

Loading comments...