[concurrency-interest] Making copy of a referencetoReentrantLock

David Holmes davidcholmes at aapt.net.au
Sat Jan 22 22:20:14 EST 2011


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> 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>> wrote:
      >> > On Sat, Jan 22, 2011 at 04:55, Rémi Forax <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
      >


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110123/7737ffb4/attachment.html>


More information about the Concurrency-interest mailing list