<br><br><div class="gmail_quote">On Thu, Nov 17, 2011 at 1:37 PM, Doug Lea <span dir="ltr"><<a href="mailto:dl@cs.oswego.edu">dl@cs.oswego.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11/17/11 06:10, √iktor Ҡlang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right now it feels like if you're doing high-perf concurrency in this sense you<br>
have to choose between:<br>
<br>
A) Cache-trashing (and extra memory usage) because you went with AtomicLong/Ref<br>
whatnot<br>
B) CPU overhead caused by Atomic*Updaters and if you do any inheritance you'll<br>
get even more checks each call (and extra mem usage due to padding).<br>
C) Sacrifice cross-platform because you had to drop down to Unsafe to get the<br>
correct machinecode emitted.<br>
<br>
</blockquote>
<br></div>
Yes.<br>
<br>
The main underlying problem is a fundamental one: Java bytecodes<br>
support only two field read/write operations (getField/putField),<br>
plus an implicit mode argument for volatiles. However, there is no<br>
casField, or special r/w modes like releaseField. One level up,<br>
there is no syntax for "lvalue" operations on fields. So the<br>
only options are to directly invoke these lvalue operations<br>
via Unsafe, which require that you know the address of the field,<br>
or to use Updaters, that don't require the address, but must<br>
perform type checks and security checks that you have access to the<br>
field.<br>
<br>
No one knows of any good alternatives. We tried for Java7<br>
to reduce need for either option by proposing Fences that<br>
would at least emulate the different memory modes, but that's<br>
also problematic enough to not be worth adopting.<br>
<br>
It's not hard to imagine some nicer syntax to support<br>
these operations (as in a.someField.compareAndSet(x, y))<br>
and also to perform class-loading-time validations (similarly<br>
to "quickening") and/or using invokeDynamic. But these matters<br>
never attain high enough priority when people consider syntax<br>
enhancements.<br>
<br>
Portability of Unsafe constructions is not really a problem.<br>
We frequently communicate with all production JVM implementors<br>
to help ensure that they are correctly supported.<br></blockquote><div><br>Alright, that's a good clarification, I've always avoided it from compatibility reasons.<br>Is this case the same with Android?<br><br>Cheers,<br>
√<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><font color="#888888">
<br>
-Doug</font><div><div></div><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.<u></u>oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/<u></u>listinfo/concurrency-interest</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Times;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><span style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">Viktor Klang<br>
<br>Akka Tech Lead</span><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><a href="http://www.typesafe.com/" target="_blank">Typesafe</a><span> </span>- Enterprise-Grade Scala from the Experts</span></font><br>
<font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font><font face="arial, sans-serif" size="2"><span style="border-collapse:collapse">Twitter: @viktorklang</span></font></div></span></span><br>