[btown]

> the child object seems to depend on memory that it doesn't own a strong reference to

Exactly. Having made similar types of robotics interfaces myself, the memory graph for OP probably isn't as complicated/cyclic as you might think: multiple types of frames (at various stages of visualization processing) look into each others' memory buffers for efficiency. It's probably best modeled as an acyclic directed graph where frame objects reference (many-to-many) memory buffers. The problem is that unless you abstract out those buffers into garbage-collectible objects themselves, it's very tempting just to pass a weak reference (like a pointer from JNI) to the buffer owned by an EarlyStageFrame to the processing code in a LaterStageFrame. Thus the segfault when the EarlyStageFrame is garbage-collected.

[amit-bansil]

That is wonderfully clear. I haven't touched much Java post nio but could the app just use something like java.nio.ByteBuffer to model the raw memory at the bottom of the graph, then have EarlyStageFrames muck with those using static native methods that take the ByteBuffers where needed and then LaterStageFrames playing with the EarlyStageFrames and reaching inside them to get at their ByteBuffers when absolutely needed for performance?

> It's probably best modeled as an acyclic directed graph

My pet theory is that a good representation for most systems should maybe always be an acyclic directed graph?

[Doradus]

Poof! There goes finite automata, and therefore regular expressions. :-)

[amit-bansil]

Fantastic examples! I would also add möbius strips, toroidal spaces, and of course, the venerated circle. Sorry, my thoughts above are poorly worded. Perhaps what I am trying to say is that cycles should be created with intentionality, instead of willy nilly spilled throughout your code base. My complaint is really with all the mad spills of Java that I created when I thought that GC was some magic wand that freed me from having to consider the structure of the memory I was manipulating.

Someone should go around sabotaging regular expression parsers and replacing them with PEGs:

http://en.wikipedia.org/wiki/Parsing_expression_grammar

It is a crime against honest words to try to cram so much logic into so few characters.

I once was told that regular expressions were originally designed for creating AIs. The image I have in my mind is that of graduate students in a dungeon somewhere banging on type writers creating some sort of God box.

[smarks]

Maybe if we get rid of regular expressions we'll have one fewer problem. :-)