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

        Howard M. Lewis Ship created issue -
        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.
        Howard M. Lewis Ship made changes -
        Field Original Value New Value
        Fix Version/s 5.1 [ 12312964 ]
        Project Tapestry [ 10573 ] Tapestry 5 [ 12310833 ]
        Key TAPESTRY-2414 TAP5-84
        Affects Version/s 5.0.11 [ 12312968 ]
        Component/s tapestry-core [ 12311285 ]
        Issue Type Improvement [ 4 ] Bug [ 1 ]
        Howard M. Lewis Ship made changes -
        Affects Version/s 5.0.15 [ 12313429 ]
        Howard M. Lewis Ship made changes -
        Issue Type Bug [ 1 ] Improvement [ 4 ]
        Howard M. Lewis Ship made changes -
        Assignee Howard M. Lewis Ship [ hlship ]
        Howard M. Lewis Ship made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        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.
        Howard M. Lewis Ship made changes -
        Summary Change proxy generation to use atomic references rather than synchronized blocks Change proxy generation to use volatile fields rather than synchronized blocks
        Howard M. Lewis Ship made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]
        Fix Version/s 5.1.0.1 [ 12313660 ]

          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