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
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
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
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
re-libs-dev@openjdk.java.net>
> > 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 Levart <peter.lev...@gmail.com>
> wrote:
> >
> >> Hi,
> >&g
- Mail original -
> De: "Vitaly Davidovich" <vita...@gmail.com>
> À: "Peter Levart" <peter.lev...@gmail.com>
> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>
> Envoyé: Jeudi 7 Décembre 2017 18:46:41
> Objet: Re: Fina
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
>
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
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
10 matches
Mail list logo