[concurrency-interest] Making copy of a referencetoReentrantLock

Navin Jha navin.jha at FXALL.com
Wed Feb 16 10:02:38 EST 2011


David,


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.

-- 
- DML


------------------------------

Message: 3
Date: Mon, 24 Jan 2011 09:41:57 +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>
Cc: concurrency-interest at cs.oswego.edu
Message-ID: <NFBBKALFDCPFIDBNKAPCAEMPIKAA.davidcholmes at aapt.net.au>
Content-Type: text/plain;	charset="iso-8859-1"

David Lloyd writes:
> >> 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.

Ouch! So you can. Those static fields are treated specially by the compiler
as explicitly not being considered constants.

David



------------------------------

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


End of Concurrency-interest Digest, Vol 72, Issue 39
****************************************************




More information about the Concurrency-interest mailing list