Details

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

      Description

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

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            genman 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
            genman 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
            arussel 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
            arussel 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 Mircea Markus added a comment -
            Show
            mircea.markus 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
            beep_beep 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
            beep_beep 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 Mircea Markus
                Reporter:
                belaban 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

                    Development