Deprecate all java.util.concurrent.*FieldUpdater

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecate all java.util.concurrent.*FieldUpdater

Remi Forax
Given that Java 9 introduces a faster way to emit things like compareAndSet by using the VarHandke API and that AtomiReference (and likes) are now rewritten to use VarHandles directly,
i think it's time to deprecate all *FieldUpdater with something saying that they have been superseded by the VarHandle API.

Rémi
substitute dr deprecator
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Martin Buchholz-3
VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet complete (where is accumulateAndGet?), and when do you deprecate something when the replacement won't be ubiquitous for 10 years?

On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <[hidden email]> wrote:
Given that Java 9 introduces a faster way to emit things like compareAndSet by using the VarHandke API and that AtomiReference (and likes) are now rewritten to use VarHandles directly,
i think it's time to deprecate all *FieldUpdater with something saying that they have been superseded by the VarHandle API.

Rémi
substitute dr deprecator


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Andrew Haley
On 04/10/16 22:19, Martin Buchholz wrote:
> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
> complete (where is accumulateAndGet?), and when do you deprecate something
> when the replacement won't be ubiquitous for 10 years?

Surely you have to start somewhere: deprecation is no more than saying
to programmers "Don't use this, use that."  And if you were leaning
over someone's shoulder that's what you would say.

Andrew.


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Justin Sampson
Deprecation is stronger than that -- it says "we're going to remove this, or we wish we could remove it because it's broken, so you'd better change your code a.s.a.p." -- e.g. Thread.stop(). My interpretation of Martin's comment is that using deprecation for things that aren't actually broken just means that people will live with lots of deprecation warnings in their code for years to come. This could be a perfect case for introducing a weaker alternative to deprecation, saying "here's something better that you should really be using for new code" -- e.g. ArrayList vs. Vector. I remember the Guava team talking about that a lot. Don't know if they ever implemented it.

Cheers,
Justin


-----Original Message-----
From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Andrew Haley
Sent: Wednesday, October 05, 2016 1:19 AM
To: Martin Buchholz; Remi Forax; Paul Sandoz
Cc: core-libs-dev; concurrency-interest
Subject: Re: [concurrency-interest] Deprecate all java.util.concurrent.*FieldUpdater

On 04/10/16 22:19, Martin Buchholz wrote:
> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
> complete (where is accumulateAndGet?), and when do you deprecate something
> when the replacement won't be ubiquitous for 10 years?

Surely you have to start somewhere: deprecation is no more than saying
to programmers "Don't use this, use that."  And if you were leaning
over someone's shoulder that's what you would say.

Andrew.


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Remi Forax
In reply to this post by Martin Buchholz-3
Hi Martin,

On October 4, 2016 11:19:33 PM GMT+02:00, Martin Buchholz <[hidden email]> wrote:
>VarHandle is a reasonable replacement for FieldUpdaters, but it's not
>yet
>complete (where is accumulateAndGet?),

Seems to be a feature for me :)
I've never liked the methods that takes a lambda in FieldUpdater. If you're using a FieldUpdater, you are in the basement, you want a reliable performance model. The JLS does not guarantee that a side effect free lambda will be always inlined.

>and when do you deprecate
>something
>when the replacement won't be ubiquitous for 10 years?

The right answer is the one from Andrew but i can not resisrt, here is my answer:
when you hope that it will not take 10 years to be ubiquitous.

regards,
Remi

>
>On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <[hidden email]> wrote:
>
>> Given that Java 9 introduces a faster way to emit things like
>> compareAndSet by using the VarHandke API and that AtomiReference (and
>> likes) are now rewritten to use VarHandles directly,
>> i think it's time to deprecate all *FieldUpdater with something
>saying
>> that they have been superseded by the VarHandle API.
>>
>> Rémi
>> substitute dr deprecator
>>

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

David M. Lloyd-3
In reply to this post by Martin Buchholz-3
I'm sure I recall an email from the past few months which proposed that
*FieldUpdater are still going to be recommended in many cases over
VarHandle because the latter is probably too low-level for casual uses.
It was (IIRC) an argument in favor of more advanced fence methods or
something like that.

Am I imagining it?

On 10/04/2016 04:19 PM, Martin Buchholz wrote:

> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
> complete (where is accumulateAndGet?), and when do you deprecate something
> when the replacement won't be ubiquitous for 10 years?
>
> On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <[hidden email]> wrote:
>
>> Given that Java 9 introduces a faster way to emit things like
>> compareAndSet by using the VarHandke API and that AtomiReference (and
>> likes) are now rewritten to use VarHandles directly,
>> i think it's time to deprecate all *FieldUpdater with something saying
>> that they have been superseded by the VarHandle API.
>>
>> Rémi
>> substitute dr deprecator
>>

--
- DML
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Aaron Grunthal
Maybe a @see on each method to inform the reader about varhandle
alternatives without deprecation?

On 05.10.2016 17:02, David M. Lloyd wrote:

> I'm sure I recall an email from the past few months which proposed that
> *FieldUpdater are still going to be recommended in many cases over
> VarHandle because the latter is probably too low-level for casual uses.
> It was (IIRC) an argument in favor of more advanced fence methods or
> something like that.
>
> Am I imagining it?
>
> On 10/04/2016 04:19 PM, Martin Buchholz wrote:
>> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
>> complete (where is accumulateAndGet?), and when do you deprecate
>> something
>> when the replacement won't be ubiquitous for 10 years?
>>
>> On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <[hidden email]> wrote:
>>
>>> Given that Java 9 introduces a faster way to emit things like
>>> compareAndSet by using the VarHandke API and that AtomiReference (and
>>> likes) are now rewritten to use VarHandles directly,
>>> i think it's time to deprecate all *FieldUpdater with something saying
>>> that they have been superseded by the VarHandle API.
>>>
>>> Rémi
>>> substitute dr deprecator
>>>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Andrew Haley
In reply to this post by Justin Sampson
On 05/10/16 15:39, Justin Sampson wrote:

> Deprecation is stronger than that -- it says "we're going to remove
> this, or we wish we could remove it because it's broken, so you'd
> better change your code a.s.a.p." -- e.g. Thread.stop().

We're moving Java to support some new ways of working, and these
changes will inevitably mean that some parts of the project will be
obsolescent.  We need to be able to flag the old ways of doing things
in some way.

Deprecation is a way to do that.  I don't think that Thread.stop() is
a typical case.

> My interpretation of Martin's comment is that using deprecation for
> things that aren't actually broken just means that people will live
> with lots of deprecation warnings in their code for years to
> come. This could be a perfect case for introducing a weaker
> alternative to deprecation, saying "here's something better that you
> should really be using for new code" -- e.g. ArrayList vs. Vector. I
> remember the Guava team talking about that a lot. Don't know if they
> ever implemented it.

OK.  But we really do need a way to do that.

Andrew.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Martin Buchholz-3
In reply to this post by Aaron Grunthal
We already added the gentlest deprecation of all of j.u.c.atomic in the package-info:

Instances of Atomic classes
 * maintain values that are accessed and updated using methods
 * otherwise available for fields using associated atomic {@link
 * java.lang.invoke.VarHandle} operations.

I'm generally negative on deprecation of stuff that works perfectly well in favor of other stuff that, even though it is clearly better in some way, is not as ubiquitous and hence less portable/compatible.  Better compatibility trumps most other kinds of "better" for most users.



On Wed, Oct 5, 2016 at 8:36 AM, Aaron Grunthal <[hidden email]> wrote:
Maybe a @see on each method to inform the reader about varhandle
alternatives without deprecation?

On 05.10.2016 17:02, David M. Lloyd wrote:
> I'm sure I recall an email from the past few months which proposed that
> *FieldUpdater are still going to be recommended in many cases over
> VarHandle because the latter is probably too low-level for casual uses.
> It was (IIRC) an argument in favor of more advanced fence methods or
> something like that.
>
> Am I imagining it?
>
> On 10/04/2016 04:19 PM, Martin Buchholz wrote:
>> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
>> complete (where is accumulateAndGet?), and when do you deprecate
>> something
>> when the replacement won't be ubiquitous for 10 years?
>>
>> On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <[hidden email]> wrote:
>>
>>> Given that Java 9 introduces a faster way to emit things like
>>> compareAndSet by using the VarHandke API and that AtomiReference (and
>>> likes) are now rewritten to use VarHandles directly,
>>> i think it's time to deprecate all *FieldUpdater with something saying
>>> that they have been superseded by the VarHandle API.
>>>
>>> Rémi
>>> substitute dr deprecator
>>>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Aaron Grunthal
In my experience users rarely read the package-info compared to class or
method infos. I guess the way IDEs display javadocs should be blamed for
that.

And they're even less likely to notice changes to those even if they
have read them in the past.

The attention ranking is members > class >> package, simply because the
way content-assist with automatic javadoc display works. Members are
most frequently accessed when typing, classes only when declaring
variables, packages get inserted automatically so you never focus on
those and thus don't see the javadocs.

Maybe IDE projects could be convinced to stack the member/class/package
hierarchy in a single view so they get equal visibility?


Also, the "using methods otherwise available" phrasing seems a bit weak
to me. I could read it as the field updaters as abstraction over the
varhandles (which they are) and conclude from that that i don't have to
concern myself with those details.
It does nothing to encourage the user to at least explore them as
alternative.



On 05.10.2016 18:11, Martin Buchholz wrote:

> We already added the gentlest deprecation of all of j.u.c.atomic in the
> package-info:
>
> Instances of Atomic classes
>  * maintain values that are accessed and updated using methods
>  * otherwise available for fields using associated atomic {@link
>  * java.lang.invoke.VarHandle} operations.
>
> I'm generally negative on deprecation of stuff that works perfectly well
> in favor of other stuff that, even though it is clearly better in some
> way, is not as ubiquitous and hence less portable/compatible.  Better
> compatibility trumps most other kinds of "better" for most users.
>
>
>
> On Wed, Oct 5, 2016 at 8:36 AM, Aaron Grunthal
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Maybe a @see on each method to inform the reader about varhandle
>     alternatives without deprecation?
>
>     On 05.10.2016 17:02, David M. Lloyd wrote:
>     > I'm sure I recall an email from the past few months which proposed that
>     > *FieldUpdater are still going to be recommended in many cases over
>     > VarHandle because the latter is probably too low-level for casual uses.
>     > It was (IIRC) an argument in favor of more advanced fence methods or
>     > something like that.
>     >
>     > Am I imagining it?
>     >
>     > On 10/04/2016 04:19 PM, Martin Buchholz wrote:
>     >> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
>     >> complete (where is accumulateAndGet?), and when do you deprecate
>     >> something
>     >> when the replacement won't be ubiquitous for 10 years?
>     >>
>     >> On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <[hidden email] <mailto:[hidden email]>> wrote:
>     >>
>     >>> Given that Java 9 introduces a faster way to emit things like
>     >>> compareAndSet by using the VarHandke API and that AtomiReference (and
>     >>> likes) are now rewritten to use VarHandles directly,
>     >>> i think it's time to deprecate all *FieldUpdater with something saying
>     >>> that they have been superseded by the VarHandle API.
>     >>>
>     >>> Rémi
>     >>> substitute dr deprecator
>     >>>
>     >
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>     <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Vladimir Ivanov
In reply to this post by Andrew Haley
>> My interpretation of Martin's comment is that using deprecation for
>> things that aren't actually broken just means that people will live
>> with lots of deprecation warnings in their code for years to
>> come. This could be a perfect case for introducing a weaker
>> alternative to deprecation, saying "here's something better that you
>> should really be using for new code" -- e.g. ArrayList vs. Vector. I
>> remember the Guava team talking about that a lot. Don't know if they
>> ever implemented it.
>
> OK.  But we really do need a way to do that.
Doesn't enhanced deprecation [1] in 9 cover that?

Best regards,
Vladimir Ivanov

[1] http://openjdk.java.net/jeps/277
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Andrew Haley
On 05/10/16 17:55, Vladimir Ivanov wrote:

>>> My interpretation of Martin's comment is that using deprecation for
>>> things that aren't actually broken just means that people will live
>>> with lots of deprecation warnings in their code for years to
>>> come. This could be a perfect case for introducing a weaker
>>> alternative to deprecation, saying "here's something better that you
>>> should really be using for new code" -- e.g. ArrayList vs. Vector. I
>>> remember the Guava team talking about that a lot. Don't know if they
>>> ever implemented it.
>>
>> OK.  But we really do need a way to do that.
> Doesn't enhanced deprecation [1] in 9 cover that?

I can't tell.  As far as I can see there is no annotation which
covers exactly our case:

    the API is flawed and is impractical to fix,

    usage of the API is likely to lead to errors,

    the API has been superseded by another API,

    the API is obsolete,

    the API is experimental and is subject to incompatible changes,

    or any combination of the above.

we'd perhaps need to add

    this method over here is better in most cases

...which perhaps implies obsolescent rather than obsolete.

Andrew.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate all java.util.concurrent.*FieldUpdater

Remi Forax
In reply to this post by Martin Buchholz-3
FieldUpdaters do not work well, at least for me !

War story/Anectode:
Updaters do unnecessary runtime casts that may lead to a deoptimization storm. I've spend several weeks in 2006/2007 on the core part of a language runtime trying to avoid that issue until I use unsafe and the problem disappear.
I've only understood what was the root cause when Paul starts to develop the VarHandle API.

Remi


On October 5, 2016 6:11:36 PM GMT+02:00, Martin Buchholz <[hidden email]> wrote:
We already added the gentlest deprecation of all of j.u.c.atomic in the package-info:

Instances of Atomic classes
 * maintain values that are accessed and updated using methods
 * otherwise available for fields using associated atomic {@link
 * java.lang.invoke.VarHandle} operations.

I'm generally negative on deprecation of stuff that works perfectly well in favor of other stuff that, even though it is clearly better in some way, is not as ubiquitous and hence less portable/compatible.  Better compatibility trumps most other kinds of "better" for most users.



On Wed, Oct 5, 2016 at 8:36 AM, Aaron Grunthal <[hidden email]> wrote:
Maybe a @see on each method to inform the reader about varhandle
alternatives without deprecation?

On 05.10.2016 17:02, David M. Lloyd wrote:
> I'm sure I recall an email from the past few months which proposed that
> *FieldUpdater are still going to be recommended in many cases over
> VarHandle because the latter is probably too low-level for casual uses.
> It was (IIRC) an argument in favor of more advanced fence methods or
> something like that.
>
> Am I imagining it?
>
> On 10/04/2016 04:19 PM, Martin Buchholz wrote:
>> VarHandle is a reasonable replacement for FieldUpdaters, but it's not yet
>> complete (where is accumulateAndGet?), and when do you deprecate
>> something
>> when the replacement won't be ubiquitous for 10 years?
>>
>> On Tue, Oct 4, 2016 at 1:32 PM, Remi Forax <[hidden email]> wrote:
>>
>>> Given that Java 9 introduces a faster way to emit things like
>>> compareAndSet by using the VarHandke API and that AtomiReference (and
>>> likes) are now rewritten to use VarHandles directly,
>>> i think it's time to deprecate all *FieldUpdater with something saying
>>> that they have been superseded by the VarHandle API.
>>>
>>> Rémi
>>> substitute dr deprecator
>>>
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest