Tapestry 5
  1. Tapestry 5
  2. TAP5-84

Change proxy generation to use volatile fields rather than synchronized blocks

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.1.0.1
    • Component/s: None
    • Labels:
      None

      Description

      As currently coded, the service proxies used for Tapestry services use a synchronized block to a) check to see if the Registry has shut down and b) obtain (if needed) the realized service implementation (wrapped by interceptors, etc.).

      It seems that with some juggling, these could largely be replaced with AtomicBoolean and AtomicReferences.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        After a brief look, using simple volatile fields seems to be the way to go, with a double-check (which is ok for volatile fields). I also found a way to eliminate the need for a volatile shutdown flag, sort of merging that back into the ObjectCreator.

        Still its hard to tell if there's a performance difference especially under JDK 1.6. Supposedly uncontested synchronized locks are super cheap in JDK 1.6 and volatiles are always more expensive than normal field access.

        Show
        Howard M. Lewis Ship added a comment - After a brief look, using simple volatile fields seems to be the way to go, with a double-check (which is ok for volatile fields). I also found a way to eliminate the need for a volatile shutdown flag, sort of merging that back into the ObjectCreator. Still its hard to tell if there's a performance difference especially under JDK 1.6. Supposedly uncontested synchronized locks are super cheap in JDK 1.6 and volatiles are always more expensive than normal field access.
        Hide
        Howard M. Lewis Ship added a comment -

        Of course, creating some benchmarks (for before and after comparisons) would be useful, to see if there's any real benefit to this. Supposedly, uncontested synchronized blocks are very cheap (and cheaper in Java 6), and access to the volatile fields inside an AtomicBoolean are going to be more expensive than ordinary field access, so there may not be any real advantage.

        Show
        Howard M. Lewis Ship added a comment - Of course, creating some benchmarks (for before and after comparisons) would be useful, to see if there's any real benefit to this. Supposedly, uncontested synchronized blocks are very cheap (and cheaper in Java 6), and access to the volatile fields inside an AtomicBoolean are going to be more expensive than ordinary field access, so there may not be any real advantage.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Howard M. Lewis Ship
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development