You can open a pull request
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Cheers,√
Hi Viktor,I've disassembled the inner closure (inner onComplete) compiled with Scala 2.11 and scalac compiles it to non-static inner class that holds reference to the enclosing closure (outer onComplete) and that enclosing closure holds reference to the function that was passed to flatMap. That obviously creates unnecessary memory leak as the inner closure doesn't need the referenece to the whole enclosing closure, it only needs access to promise that is returned from flatMap.
Nevertheless, compiling source code taken from before implemeting promise linking and compiling it with Scala 2.12 resulted in bytecode that didn't have that memory leak and therefore `feedPromise` wasn't needed to pass the tests that you've described in your blog.
But as you've said, even without unnecessary closure over functions passed to flatMap/ transformWith/ whatever we're still left with strongly referenced promises chain if we don't do promises linking. I've added UnboundedAcpsTests.scala to my project to check that and with small enough -Xmx (eg -Xmx10m) it's easy to see that only with promises linking we're getting a program that happily runs forever without memory space exceptions/ errors.
So I'm back to the point where I don't understand how promise linking solve problems :)
But at least the description you've shown on you blog is misleading - the leaking arrays are due to compiler deficiency, not due to promises chaining. Promises linking seems to solve problem of long chains of promises, but we don't need any complicated closures closing over big state to show that.
I have an idea about inverting the direction of promise linking - ie linking from newer promise to older promise. This way we shouldn't need to migrate callbacks over and over as they all would accumulate at the oldest promise. However, I have yet to fully understand how promise linking works in current Scala library to start implementing and testing my own.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.
I think I've understood the promise linking now. Before I thought that older promises were pointing to newer promises, but actually it's the other way around, thus my idea about reversing direction of promise linking is invalid.
As for the example, I think that you should remove the leaking arrays as those leaks are related to compiler deficiency, not promises chains. So basically the tests that I've included in UnboundedAcpsTests.scala show the problem accurately - without promise linking we're slowly building up a promise callback chain that can't be garbage collected. But the pace at which the memory usage grows is very low so setting low Xmx (eg to 10m) is crucial as otherwise user would need to wait a long time for memory exhaustion exception.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.