Your Digital Media Has Never Looked So Good

 
sjb64
Topic Author
Posts: 108
Joined: Thu Apr 16, 2015 1:13 pm
Location: Memphis, TN

Orphaned objects - circular ref loop

Thu Sep 17, 2015 3:00 pm

If I intentionally use circular references, and as a result get the GC note on application close, am I doing something that the internal Roku runtime is going to choke on at a certain point?

I have a core data payload that lives for the duration of the application - these records are never deleted once loaded, and they are cross linked. So an example is that a movie can point to several episodes (children), an episode can point to a movie (parent), so even on a one to one movie to episode pair, this creates a circular reference. I could just store the IDs then deference the reassociatedarray, but it seemed more efficient to run those deref's in a single pass on startup than multiple times during user interaction.

I know this could start a whole discussion of best practices, pre linking vs as needed linking, that all relational databases are by definition circular unless normalized, etc. But my question is simply is the message just informative, or a warning that it can upset, interfere with, fragment, or even corrupt the GC or app environment.
FlixRaider channel
 
User avatar
RokuJoel
Posts: 1758
Joined: Mon Nov 14, 2011 5:22 pm

Re: Orphaned objects - circular ref loop

Fri Sep 18, 2015 5:42 pm

If it isn't crashing your channel due to stack overflow, I suspect it is fine.

- Joel
 
EnTerr
** Valued Community Member **
Posts: 3834
Joined: Sun Jan 02, 2011 2:41 am

Re: Orphaned objects - circular ref loop

Sat Sep 19, 2015 10:09 am

I believe the message is just informative. Being "internal use", console messages are not particularly well thought out (case in point, the crappy format of the warning messages).

My recollection is for B/S memory manager uses reference counting + GC, just like Python. This way simple objects get released right away when de-referenced (to 0), where orphaned cyclic structures get reaped by the Grim Collector on exit or low-memory condition. I think that makes for more acceptable behavior when dealing with humans on low memory/CPU devices vs periodic freezes from JVM/Android. And this particular GC tends to be a crank, muttering under breath while brooming

Who is online

Users browsing this forum: No registered users and 14 guests