Details

    • Type: Feature Request Feature Request
    • Status: Open Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.3.0.GA
    • Component/s: Eviction
    • Labels:
      None
    • Estimated Difficulty:
      Medium
    • Similar Issues:
      Show 9 results 

      Description

      (maybe only in JDK 1.5, which has
      triggers for low memory)

        Issue Links

          Activity

          Hide
          Elias Ross
          added a comment -

          I was thinking of implementing something like this, since it's fairly straightfoward. Or so I thought....

          Eviction based on, say a fraction of total free memory, would make sense. In Java 1.5, it is easy to get the MXBean that return heap information, etc.

          What users might want to do is specify how much memory is allocated for a particular cache (region), or to a percentage of the maximum heap storage for caching... not to simply evict on some arbitrary percentage of memory free. Somehow this seems a bit unstable.

          If it were possible, calcuating a cache's exact memory footprint would be ideal. I believe, though, with some sort of sampling (and maybe by serializing the data itself), a "good enough" estimate could be obtained. And actually, providing an estimated size of the cache (in bytes) would be useful to know as a user. For commonly-kept objects (such as "String" or "integer"), using the Java "SizeOf" program should produce a good size estimate of these types. Sampling should be done randomly, of course, and if just perhaps 1% of the objects were sampled,

          Show
          Elias Ross
          added a comment - I was thinking of implementing something like this, since it's fairly straightfoward. Or so I thought.... Eviction based on, say a fraction of total free memory, would make sense. In Java 1.5, it is easy to get the MXBean that return heap information, etc. What users might want to do is specify how much memory is allocated for a particular cache (region), or to a percentage of the maximum heap storage for caching... not to simply evict on some arbitrary percentage of memory free. Somehow this seems a bit unstable. If it were possible, calcuating a cache's exact memory footprint would be ideal. I believe, though, with some sort of sampling (and maybe by serializing the data itself), a "good enough" estimate could be obtained. And actually, providing an estimated size of the cache (in bytes) would be useful to know as a user. For commonly-kept objects (such as "String" or "integer"), using the Java "SizeOf" program should produce a good size estimate of these types. Sampling should be done randomly, of course, and if just perhaps 1% of the objects were sampled,
          Hide
          alexandre russel
          added a comment -

          Hi,
          a patch not meant to be comited but to get things started.
          the idea is to separate:
          when is there eviction => decided by EvictionTask.
          which node is evicted => decided by the algorithm.
          how many are evicted => decided by the number of nodes in the cache.

          The patch keep the algoritm. It creates an abstract class EvictionTask,
          with 2 child EvictionTimerTask (the previous EvictionTask) and
          EvictionMemoryTask (a new EvictionTask based on memory).

          I added setter and getter on EvictionPolicyConfig for maxNodes.

          The EvictionMemoryTask listen to the memory pool that support usage threshold
          and that matches a regexp given in config.
          It accept 2 settings, a minimum and a maximum percentage of memory.
          When there is a notification that the first minimum of memory is
          exceded, the maximum number of nodes is set to half its value.
          If it goes over the maximum percentage the maximum number of nodes goes to 1.

          I used sun's jvm. If you run the test, you may want to check the number
          of objects put in the list. It was set to be a raisonable value on my
          computer.

          If you think it is a good way to add memory based eviction, let me know
          and I'll improve on it. (Few improvements would be to be able to increment
          max nodes when memory is back to a low value and have more than just 2 values
          max and min)
          alex

          Show
          alexandre russel
          added a comment - Hi, a patch not meant to be comited but to get things started. the idea is to separate: when is there eviction => decided by EvictionTask. which node is evicted => decided by the algorithm. how many are evicted => decided by the number of nodes in the cache. The patch keep the algoritm. It creates an abstract class EvictionTask, with 2 child EvictionTimerTask (the previous EvictionTask) and EvictionMemoryTask (a new EvictionTask based on memory). I added setter and getter on EvictionPolicyConfig for maxNodes. The EvictionMemoryTask listen to the memory pool that support usage threshold and that matches a regexp given in config. It accept 2 settings, a minimum and a maximum percentage of memory. When there is a notification that the first minimum of memory is exceded, the maximum number of nodes is set to half its value. If it goes over the maximum percentage the maximum number of nodes goes to 1. I used sun's jvm. If you run the test, you may want to check the number of objects put in the list. It was set to be a raisonable value on my computer. If you think it is a good way to add memory based eviction, let me know and I'll improve on it. (Few improvements would be to be able to increment max nodes when memory is back to a low value and have more than just 2 values max and min) alex
          Hide
          Mircea Markus
          added a comment -
          Show
          Mircea Markus
          added a comment - some interesting articles on how JVM allocates memory: http://javaspecialists.co.za/archive/Issue029.html + http://blog.evver.com/2007/08/14/boolean-memory-use/
          Hide
          Peter Kovgan
          added a comment -

          Alexandre Russel hi!
          In general I agree on that.
          It's good idea.

          But,
          Why not start partly eviction in first point? (Not changing maxNodes)
          Then on second point start complete eviction + change MaxNodes(how much - parameter)?

          Peter.

          Show
          Peter Kovgan
          added a comment - Alexandre Russel hi! In general I agree on that. It's good idea. But, Why not start partly eviction in first point? (Not changing maxNodes) Then on second point start complete eviction + change MaxNodes(how much - parameter)? Peter.

            People

            • Assignee:
              Mircea Markus
              Reporter:
              Bela Ban
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 2 weeks
                2w
                Remaining:
                Remaining Estimate - 2 weeks
                2w
                Logged:
                Time Spent - Not Specified
                Not Specified