search

viktorklang / blog

Letters from Klang
230 stars 21 forks source link

Futures in Scala 2.12: Part 8 — sun.misc.Unsafe #11

Closed viktorklang closed 8 years ago

slandelle commented 8 years ago

Hi Viktor,

This post is very frustrating: you only tell the beginning and the end of the story! What about the journey? :)

AtomicReference was there from the beginning, so why originally go with ARFU? How is it that you were capable of getting the same performance with AR? Did AR performance improved in JDK8?

Cheers, and thanks a lot!

viktorklang commented 8 years ago

Hi @slandelle, Good point, I'll issue an update and try to flesh that out :) It's not going to be what you think :)

slandelle commented 8 years ago

It's not going to be what you think :)

Oh man, the cliffhanger!

viktorklang commented 8 years ago

@slandelle Alright, updated the post to contain more history :)

He-Pin commented 8 years ago

@slandelle one thing I know is http://normanmaurer.me/blog/2013/10/28/Lesser-known-concurrent-classes-Part-1/

slandelle commented 8 years ago

@hepin1989 Yes, I was aware of Norman's post. So having AtomicReference perform better than ARFU would mean raw speed would compensate for additional GC?

slandelle commented 8 years ago

with extending AtomicReference internally

Smart! Thanks @viktorklang

viktorklang commented 8 years ago

@slandelle :-) Thank you for helping me improve the blog post, I hope you enjoyed the reading

slandelle commented 8 years ago

@viktorklang Absolutely, thanks a lot for sharing! FYI, I just ping'ed the Netty guys: https://github.com/netty/netty/issues/4922. Hunting FieldUpdaters down now :)

He-Pin commented 8 years ago

@slandelle http://shipilev.net/blog/2015/faster-atomic-fu/ here is another one. the real story should waiting for the update,but I think ,Future have only 1 value,that's ok.

slandelle commented 8 years ago

@hepin1989 Thanks for the link

metasim commented 8 years ago

Why didn't the original implementation take the approach of extending AtomicReference? Was it just an evolution in the design, or was it something new made available in Java 8?

viktorklang commented 8 years ago

@metasim Hmmm, good question. Perhaps @axel22 knows? https://github.com/scala/scala/blob/ab84c8d9a97b41728e77f7808eda2748d052ca06/src/library/scala/concurrent/impl/AbstractPromise.java

axel22 commented 8 years ago

Not sure, possibly because performance differences are not so large in real programs. One would have to benchmark large future-heavy applications to measure the difference.

Decisions could date back even earlier to this:

https://github.com/scala/scala/commit/2c01191b99d912f99a7d50be693d09406761a94c#diff-a7acaf0de3e4f9297f5d9b507be3d2cbR64

viktorklang commented 8 years ago

Ah! Also, there was the retracted @static annotation that would have obviated the need for the AbstractPromise class.

Cheers, √ On Mar 14, 2016 23:34, "Aleksandar Prokopec" notifications@github.com wrote:

Not sure, possibly because performance differences are not so large in real programs. One would have to benchmark large future-heavy applications to measure the difference.

Decisions could date back even earlier to this:

scala/scala@2c01191#diff-a7acaf0de3e4f9297f5d9b507be3d2cbR64 https://github.com/scala/scala/commit/2c01191b99d912f99a7d50be693d09406761a94c#diff-a7acaf0de3e4f9297f5d9b507be3d2cbR64

— Reply to this email directly or view it on GitHub https://github.com/viktorklang/blog/pull/11#issuecomment-196549600.