[concurrency-interest] Making copy of a referencetoReentrantLock

Brian Goetz brian at briangoetz.com
Wed Feb 16 12:21:40 EST 2011


As a general rule, you can not draw any general conclusions about "black 
performance magic."  I understand that it is natural to want to distill 
a set of "best practices" for high-performance code, but such things 
don't really exist.  Most of these tricks are ad-hoc, VM-specific (both 
product and version), statistical in nature, moving targets as VMs 
evolve, etc.  The list of "but it depends on" qualifiers for statements 
like this is about as long as the VM source code.

Sorry :(

> Sorry to bring this up again. Can I draw a general conclusion from this discussion that when you have a method that needs to be very efficient (e.g. handling market data in a trading application) in a multi-threaded environment you should look to make local copies of final variables (and even other variable which you don't expect to change going forward)?
>
> -Navin
>
>
>
>
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of concurrency-interest-request at cs.oswego.edu
> Sent: Monday, January 24, 2011 12:00 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: Concurrency-interest Digest, Vol 72, Issue 39
>
> Send Concurrency-interest mailing list submissions to
> 	concurrency-interest at cs.oswego.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> or, via email, send a message with subject or body 'help' to
> 	concurrency-interest-request at cs.oswego.edu
>
> You can reach the person managing the list at
> 	concurrency-interest-owner at cs.oswego.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Concurrency-interest digest..."
>
>
> Today's Topics:
>
>     1. Re: Making copy of a referencetoReentrantLock (David Holmes)
>     2. Re: Making copy of a referencetoReentrantLock (David M. Lloyd)
>     3. Re: Making copy of a referencetoReentrantLock (David Holmes)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 24 Jan 2011 08:30:03 +1000
> From: "David Holmes"<davidcholmes at aapt.net.au>
> Subject: Re: [concurrency-interest] Making copy of a
> 	referencetoReentrantLock
> To: "David M. Lloyd"<david.lloyd at redhat.com>,
> 	<concurrency-interest at cs.oswego.edu>
> Message-ID:<NFBBKALFDCPFIDBNKAPCCEMOIKAA.davidcholmes at aapt.net.au>
> Content-Type: text/plain;	charset="iso-8859-1"
>
> David,
>
>> There's a bit more to it than that.  System.in/out/err are "special" in
>> that they are final but can be reloaded in the normal course of program
>> execution.
>
> But that happens during VM initialization and is covered by "before they are
> made available for access by other parts of a program" clause.
>
> I guess all this just reinforces why finals are tricky to handle and hence
> why the j.u.c code loads finals into locals.
>
> David Holmes
>
>> On 01/22/2011 09:20 PM, David Holmes wrote:
>>> Remi,
>>> The specification makes it clear that setting of a final field via
>>> reflection is only valid in certain contexts:
>>> "Setting a final field in this way is meaningful only during
>>> deserialization or reconstruction of instances of classes with blank
>>> final fields, before they are made available for access by other parts
>>> of a program. Use in any other context may have unpredictable effects,
>>> including cases in which other parts of a program continue to use the
>>> original value of this field. "
>>> So the compiler can optimize away re-loading of final fields, even if
>>> reflection (or Unsafe) is mis-used. (Though compilation of
>>> deserialization code would have to be handled specially.)
>>> David
>>>
>>>      -----Original Message-----
>>>      *From:* R?mi Forax [mailto:forax at univ-mlv.fr]
>>>      *Sent:* Sunday, 23 January 2011 10:49 AM
>>>      *To:* dholmes at ieee.org
>>>      *Cc:* David Holmes; Vitaly Davidovich;
>>>      concurrency-interest at cs.oswego.edu
>>>      *Subject:* Re: [concurrency-interest] Making copy of a
>>>      referencetoReentrantLock
>>>
>>>      On 01/23/2011 01:37 AM, David Holmes wrote:
>>>>      Re-loading a final field is always redundant, the question is
>>>>      whether the compiler recognizes that regardless of method calls or
>>>>      inlining. It didn't in the past. I dont know what it does now.
>>>
>>>      You can't optimize re-loading of final field if the field is changed
>>>      (by reflection or using unsafe) in the middle.
>>>      That why it depends on method calls/inlining.
>>>
>>>      The other solution is optimize optimistically and deopt if someone
>>>      changes the field.
>>>      Hotspot don't do that.
>>>
>>>>      Remi:thanks for correcting my comment on final locals.
>>>>      Cheers,
>>>>      David
>>>
>>>      regards,
>>>      R?mi
>>>
>>>>          -----Original Message-----
>>>>          *From:* concurrency-interest-bounces at cs.oswego.edu
>>>>          [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf
>>>>          Of *Vitaly Davidovich
>>>>          *Sent:* Sunday, 23 January 2011 9:21 AM
>>>>          *To:* R?mi Forax
>>>>          *Cc:* Martin Buchholz; concurrency-interest at cs.oswego.edu
>>>>          *Subject:* Re: [concurrency-interest] Making copy of a
>>>>          referencetoReentrantLock
>>>>
>>>>          I guess you're talking about final field loads across method
>>>>          calls by mentioning inlining; if so, clearly inlining exposes
>>>>          opportunities for optos, but I'm personally curious whether
>>>>          all loads are eliminated within one method - seems you're
>>>>          saying that's the case (I should take a look at the
>>>>          disassembly myself and not be lazy :)). Furthermore, with
>>>>          respect to the original question, interesting to know whether
>>>>          lock() and the like prevent this opto in the latest product
>>>>          hotspot.
>>>>
>>>>          On Jan 22, 2011 6:03 PM, "R?mi Forax"<forax at univ-mlv.fr
>>>>          <mailto:forax at univ-mlv.fr>>  wrote:
>>>>          >  On 01/22/2011 10:24 PM, Vitaly Davidovich wrote:
>>>>          >>
>>>>          >>  Martin,
>>>>          >>
>>>>          >>  Are you saying that the current (e.g. jdk 6u23) C2 compiler
>>>>          (let's
>>>>          >>  focus on this one) does not eliminate repeated loads of
>>>>          final fields
>>>>          >>  even in trivial methods (i.e. no mem fences)? I'd imagine
>>>>          that's a
>>>>          >>  failure in the compiler if that's true. Style/engineering
>>>>          practices
>>>>          >>  aside, developers should not have to resort to manually
>>>>          optimizing a
>>>>          >>  final read by using a local. I'm still curious to hear from
>>>>          someone
>>>>          >>  on the compiler team on this subject.
>>>>          >>
>>>>          >>  Vitaly
>>>>          >>
>>>>          >
>>>>          >  c1 and c2 eliminate redundant loads (as far as I can see by
>>>>          playing with
>>>>          >  hsdis),
>>>>          >  but for that all the bytecodes between the two loads must be
>>>>          inlined.
>>>>          >  It's often the case with c2, c1 is less aggressive.
>>>>          >
>>>>          >  R?mi
>>>>          >
>>>>          >>  On Jan 22, 2011 3:35 PM, "Martin Buchholz"
>>>>          <martinrb at google.com<mailto:martinrb at google.com>
>>>>          >>  <mailto:martinrb at google.com<mailto:martinrb at google.com>>>
>>>>          wrote:
>>>>          >>  >  On Sat, Jan 22, 2011 at 04:55, R?mi Forax
>>>>          <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>
>>>>          >>  <mailto:forax at univ-mlv.fr
>> <mailto:forax at univ-mlv.fr>>>  wrote:
>>>>          >>  >
>>>>          >>  >>
>>>>          >>  >>  No, making the local final doesn't trigger any
>> optimization.
>>>>          >>  >>  javac doesn't do any optimization and in the bytecode
>>>>          there is no
>>>>          >>  way to
>>>>          >>  >>  say this local variable is final.
>>>>          >>  >>
>>>>          >>  >
>>>>          >>  >  We in jsr166-land consider our software important enough
>>>>          to make
>>>>          >>  >  optimizations we don't recommend to regular java
>>>>          programmers.
>>>>          >>  Copying final
>>>>          >>  >  fields to locals generates smaller bytecode and might
>>>>          help the jit
>>>>          >>  produce
>>>>          >>  >  better code (and with current hotspot, still does).
>>>>          >>  >
>>>>          >>  >  Using final on locals has no performance advantage, but
>>>>          it does have
>>>>          >>  some
>>>>          >>  >  software engineering advantages. We tend to use it for
>>>>          locals with
>>>>          >>  the same
>>>>          >>  >  name as a field, e.g.
>>>>          >>  >
>>>>          >>  >  final Foo foo = this.foo;
>>>>          >>  >
>>>>          >>  >  Martin
>>>>          >
>>>
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>> --
>> - DML
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 23 Jan 2011 17:03:04 -0600
> From: "David M. Lloyd"<david.lloyd at redhat.com>
> Subject: Re: [concurrency-interest] Making copy of a
> 	referencetoReentrantLock
> To: dholmes at ieee.org
> Cc: concurrency-interest at cs.oswego.edu
> Message-ID:<4D3CB3A8.2060103 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 01/23/2011 04:30 PM, David Holmes wrote:
>> David,
>>
>>> There's a bit more to it than that.  System.in/out/err are "special" in
>>> that they are final but can be reloaded in the normal course of program
>>> execution.
>>
>> But that happens during VM initialization and is covered by "before they are
>> made available for access by other parts of a program" clause.
>
> However, you can call System.setIn/Out/Err() at any time, thus it's not
> exclusively relegated to VM init.
>


More information about the Concurrency-interest mailing list