On 12/07/2017 07:22 PM, Peter Levart wrote:
On 12/07/2017 06:46 PM, Vitaly Davidovich wrote:
So no magic here. Just API.
This is an API version of Hans’s #3 approach. As he said, there’s
performance overhead and nothing guarantees that the referent is kept
alive - that’s an implement
Hi Remi,
On 12/07/2017 07:12 PM, Remi Forax wrote:
So no magic here. Just API.
This is an API version of Hans’s #3 approach. As he said, there’s
performance overhead and nothing guarantees that the referent is kept alive
- that’s an implementation artifact.
it's not even true, the implementat
On Thu, Dec 7, 2017 at 1:22 PM, Peter Levart wrote:
>
>
> On 12/07/2017 06:46 PM, Vitaly Davidovich wrote:
>
> So no magic here. Just API.
>
> This is an API version of Hans’s #3 approach. As he said, there’s
> performance overhead and nothing guarantees that the referent is kept alive
> - that’
On 12/07/2017 06:46 PM, Vitaly Davidovich wrote:
So no magic here. Just API.
This is an API version of Hans’s #3 approach. As he said, there’s
performance overhead and nothing guarantees that the referent is kept
alive - that’s an implementation artifact.
I think without the VM knowi
On Thu, Dec 7, 2017 at 1:12 PM, Remi Forax wrote:
> - Mail original -
> > De: "Vitaly Davidovich"
> > À: "Peter Levart"
> > Cc: "core-libs-dev"
> > Envoyé: Jeudi 7 Décembre 2017 18:46:41
> > Objet: Re: Finalization and de
- Mail original -
> De: "Vitaly Davidovich"
> À: "Peter Levart"
> Cc: "core-libs-dev"
> Envoyé: Jeudi 7 Décembre 2017 18:46:41
> Objet: Re: Finalization and dead references: another proposal
> On Thu, Dec 7, 2017 at 12:28 PM Peter Levar
On Thu, Dec 7, 2017 at 12:28 PM Peter Levart wrote:
> Hi,
>
> On 12/07/2017 03:27 AM, Vitaly Davidovich wrote:
> > So kind of the opposite of WeakReference - a SuperStrongReference :).
> >
> > Kidding aside, it seems like the way you’d want to encapsulate this at
> the
> > language level is via a
Hi,
On 12/07/2017 03:27 AM, Vitaly Davidovich wrote:
So kind of the opposite of WeakReference - a SuperStrongReference :).
Kidding aside, it seems like the way you’d want to encapsulate this at the
language level is via a type that the JVM intrinsically knows about; in
this way it’s similar to
Hi,
I'm trying to read the rules and imagine cases where they would not work...
/A field declared to be reachability-sensitive is reachability-safe. An
access a to a reachability-safe field of object p inside a (possibly
static) method in p’s class, results in the introduction of
reachabilit
On Wed, Dec 6, 2017 at 7:38 PM Hans Boehm wrote:
> We're still trying to deal with a fair amount of code that implicitly
> assumes that finalization or similar clean-up will not occur while a
> pointer to the affected object is in scope. Which is of course not true.
>
> As a reminder, the canonic
10 matches
Mail list logo
