Sign in to follow this  

[java] Reachability of temporaries

This topic is 4394 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

For an assignment I have to write a few audio filters using the javax.sound.sampled package. You are given bytes, which you have to combine into samples, then separate the channels, apply the filters, interleave the channels and finally convert it back to bytes. To me it seems most natural to represent all this data using linked lists. (Using streams is also possible, but it's a bit more bothersome, as the original data stream is ephemeral (can only be read once), and hence buffers are needed, and I'd prefer to have something cleaner than that) Using "regular" linked lists is quite expensive in terms of memory though, so I tried implementing Haskell's lazy lists in java: cons-cells are only constructed when actually needed. I also rely on the fact that cons-cells which are not needed anymore become unreachable and can be reclaimed by the GC. This way, I can code my filters as if I were working on regular linked lists, while in reality only a small fraction of the list exists in memory. However, I bumped into unexpected behavior:
LazyList<Byte> loadByteList(String file);
LazyList<Byte> applyFilters(LazyList<Byte> input);

LazyList<Byte> output = applyFilters( loadByteList("input.wav") );
It seems the cons-cell loadByteList returns still exists while applyFilters is running so that it is still reachable and hence no cons-cells can be reclaimed by the GC, resulting in high memory consumption (and slowdowns due to the frequent GC-cycles, after which a OutOfMemory error gives the coup de grâce). So, in a way, temporaries stay reachable beyond their lifetime. I've checked if other 2 languages behave like this: OCaml and C# do not to seem to have this problem. This leads me to the following two questions: a) is there a specific reason java wants temporaries to remain reachable? b) is there an easy way to detect which objects are reachable so that I can quickly find the culprit when I run into this kind of situation again?

Share this post


Link to post
Share on other sites
I'm guessing that it's in the 'Invisible' lifecycle state. Apparently, try {...} catch {...} blocks can also create this problem. link

Keeping track of your lists with weak references might help you at least track down the source of future problems. I've never had to do this myself so I don't know what's involved - this link might have some useful information though.

Share this post


Link to post
Share on other sites
I didn't know about the invisible references, I guess my problem falls under that category. I find it strange that optimisations that can lead to memory leaks are allowed, GC becomes quite a leaky abstraction this way.

Thank you for your links and suggestions.

Share this post


Link to post
Share on other sites

This topic is 4394 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this