GeoTools
  1. GeoTools
  2. GEOT-933

Investigate SoftReferences for Caching time-expensive objects.

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.7-M0
    • Component/s: render
    • Labels:
      None

      Description

      It might be worth to consider using SoftReferences instead of WeakReferences since, especially on the server JVM it is easy to control the time between the marking and the deletion making it possible to keep them in memory for longer time. All this can be done via a secific JVM hint (that I don't remember now : ).

      WeakReferences are almost useless in a server side environment since they get garbaged pretty quickly. Recommendation from many authors is to use SoftReference objects insteads especially when caching objects tha requires a lot of time at creation like a CRS built from a db backed authorithy.

        Issue Links

          Activity

          Hide
          Martin Desruisseaux added a comment -
          SoftReferences are clearly appropriate for reasonably small objects that are costly to compute. CRS backed by an EPSG database may fall in this category (GEOT-932). However WeakReferences are more appropriate for big immutable objects that are cheap to construct but advantageous to share. LookupTables may fall in this category (GEOT-1092). In this later case, the purpose of WeakReference is not to cache, but to share instances that are already in use somewhere else in the JVM in order to reduce memory usage, which is an other way to improve performances. In this case, fast garbage collection of WeakReference is exactly what we want.

          So sometime weak references are more appropriate even in a server environment. It is a balance between the cost for computing the objects and the memory they consume. If the objects are small but costly to compute, use SoftReferences up to some limit (see below). If the objects are big, shareable (i.e. immutable) but cheap to compute, use WeakReference. If they are both big and costly to compute, then I have no clear answer... The tradeoff is often non-obvious.

          Note: when using SoftReference, we should avoid retaining thousands of old objects that may never be used again. Even if SoftReferences are cleared when memory are needed, it still put some additional pressure on the garbage collector, reduce the amount of memory available to other applications and may increase the frequency of disk swapping. Soft references in a LRU cache is probably a good compromise.

          I have to said that I have no profiling for backing my words. All this comment is based only on feeling.
          Show
          Martin Desruisseaux added a comment - SoftReferences are clearly appropriate for reasonably small objects that are costly to compute. CRS backed by an EPSG database may fall in this category ( GEOT-932 ). However WeakReferences are more appropriate for big immutable objects that are cheap to construct but advantageous to share. LookupTables may fall in this category ( GEOT-1092 ). In this later case, the purpose of WeakReference is not to cache, but to share instances that are already in use somewhere else in the JVM in order to reduce memory usage, which is an other way to improve performances. In this case, fast garbage collection of WeakReference is exactly what we want. So sometime weak references are more appropriate even in a server environment. It is a balance between the cost for computing the objects and the memory they consume. If the objects are small but costly to compute, use SoftReferences up to some limit (see below). If the objects are big, shareable (i.e. immutable) but cheap to compute, use WeakReference. If they are both big and costly to compute, then I have no clear answer... The tradeoff is often non-obvious. Note: when using SoftReference, we should avoid retaining thousands of old objects that may never be used again. Even if SoftReferences are cleared when memory are needed, it still put some additional pressure on the garbage collector, reduce the amount of memory available to other applications and may increase the frequency of disk swapping. Soft references in a LRU cache is probably a good compromise. I have to said that I have no profiling for backing my words. All this comment is based only on feeling.
          Hide
          Andrea Aime added a comment -
          Afaik we use only soft referencig in the rendering subsystem now
          Show
          Andrea Aime added a comment - Afaik we use only soft referencig in the rendering subsystem now
          Hide
          Andrea Aime added a comment -
          Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update
          Show
          Andrea Aime added a comment - Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update

            People

            • Assignee:
              Jesse Eichar
              Reporter:
              Simone Giannecchini
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: