Re: Ephemerons

> On Jan 24, 2016, at 12:14 PM, Peter Levart wrote: > > Hi Gil, > > The algorithm complexity has been on my mind too and I've been thinking of > how to maintain a key (or it's address) -> ephemeron mapping most efficiently. This can vary. It's possible to do true O(1) reverse reference lookup

Re: Ephemerons

Hi Gil, The algorithm complexity has been on my mind too and I've been thinking of how to maintain a key (or it's address) -> ephemeron mapping most efficiently. As I have written in a reply to Mandy, if we say that individual phase2 of processing of the normal References has complexity O(N)

Re: Ephemerons

A note on implementation possibilities: If I read the implementation correctly, a "weakness" of the current implementation approach for making sure value-referents (and their transitively reachable) objects are kept alive if key referents are alive is that it requires multiple passes through th

Re: Ephemerons

Hi Gil, I totally agree with your assessment. We should not introduce another way of reviving the almost collectable objects and I fully support tightening the specification so that soft and weak references to the same referent and to other referents from which this referent is reachable are

Re: Ephemerons

> On Jan 23, 2016, at 5:14 AM, Peter Levart wrote: > > Hi Gil, it's good to have this discussion. See comments inline... > > On 01/23/2016 05:13 AM, Gil Tene wrote: > >>> On Jan 22, 2016, at 2:49 PM, Peter Levart < >>> peter.lev...@gmail.com >>>

Re: Ephemerons

Hi Gil, it's good to have this discussion. See comments inline... On 01/23/2016 05:13 AM, Gil Tene wrote: On Jan 22, 2016, at 2:49 PM, Peter Levart > wrote: Ephemeron always touches definitions of at least two consecutive strengths of reachabilities. The pro

Re: Ephemerons

> On Jan 22, 2016, at 2:49 PM, Peter Levart wrote: > > Hi Gil, > > Thanks for taking a look at the Ephemerons for Java. It's great to have a big > mind joining the discussion. > > On 01/22/2016 07:12 PM, Gil Tene wrote: >> Peter, >> >> I've been following Ephemerons in other GC'ed environmen

Re: Ephemerons

> On Jan 22, 2016, at 2:49 PM, Peter Levart wrote: > > Hi Gil, > > Thanks for taking a look at the Ephemerons for Java. It's great to have a big > mind joining the discussion. > > On 01/22/2016 07:12 PM, Gil Tene wrote: >> Peter, >> >> I've been following Ephemerons in other GC'ed environmen

Re: Ephemerons

Hi Gil, Thanks for taking a look at the Ephemerons for Java. It's great to have a big mind joining the discussion. On 01/22/2016 07:12 PM, Gil Tene wrote: Peter, I've been following Ephemerons in other GC'ed environments, and wondering when someone will bring it up for Java. Happy to see at

Re: Ephemerons

Peter, I've been following Ephemerons in other GC'ed environments, and wondering when someone will bring it up for Java. Happy to see attentions given to it. The "conditional weak reference hashmap/table/dictionary" use case seems to be a common primary motivator, and it's a very valid one. Giv

Re: Ephemerons

Hi Peter, On 22/01/16 12:10, Peter Levart wrote: > Thanks for noticing this post. ... Hey, I noticed it too! I think it's a good proposal very clearly explained and well thought through (as so often when you post). I have not commented because I don't really have a good use case against which to

Re: Ephemerons

Hi Mandy, Thanks for noticing this post. I think Ephemerons would be a nice tool that would solve some "memory leak" problems people have when using data structures with weak references. On 01/20/2016 05:20 PM, Mandy Chung wrote: Hi Peter, This is interesting and useful for cases when key/v

Re: Ephemerons

Hi Peter, This is interesting and useful for cases when key/value in a reference chain cycle. This seems worth exploring for a future release. I don’t have any cycle to study this in depth and begin any discussion unfortunately at this time. Have you tried prototype Ephemerons with WeakRefer