Details

    • Type: Sub-task Sub-task
    • Status: In Progress In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1000
    • Component/s: Runtime: JMX
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The memory management facilities are split over four beans, which divide the concept into general memory managers, garbage collectors and resource pools. The main issue will be working out how many memory manager/garbage collector beans to return, and how to interact with MMTK to get the required data.

      Rather than returning simple values, these return new instances of classes which provide quite a lot of data about memory usage. The minimum implementation should not be too complex, but adding a lot of the optional timing mechanisms will take a while.

        Activity

        Andrew John Hughes made changes -
        Field Original Value New Value
        Parent RVM-127 [ 53569 ]
        Issue Type New Feature [ 2 ] Sub-task [ 7 ]
        Hide
        Andrew John Hughes added a comment -

        I've succeeded in working out pretty much which and how many beans we need to represent MMTk. We map each MMTk Space to a JMX memory pool, while a single GarbageCollector bean (which also serves as a memory manager bean) represents the active MMTk plan.

        The pools are proving the most complicated to implement as they have the most functionality. Moreover, they require monitoring of events within the memory system that could affect performance. Fortunately many of them are optional, so even if we do implement them we could have them turned on only by a command line option in the same way that compiler timing is controlled.

        The functions basically come down to usage monitoring: current, peak and 'collection'. The first is easy enough because it just requires probing the pool on request. The others are more tricky as they require storing additional information. Peak usage seems an particularly tricky thing to monitor with regard to performance as it means we need to check the new usage levels each time something is allocated and see if we have a new peak.

        There is also a notion of thresholds for collection and normal usage, which again would require constant monitoring. We already seem to have a collection usage threshold, but it applies to the whole Plan as a whole and not the individual Spaces. These thresholds are however optional, unlike peak usage monitoring.

        So far, I've implemented all the fairly simple stuff (like current usage, pool type, etc.), so I just need to work out how to handle peak usage and whether we want to have (or already do have) support for the thresholds.

        The memory manager seems like it will be quite a bit simpler, mainly because there's only one of them! It also only contains four methods in total, and the ones for the general memory manager are trivial (it's always valid and its memory pools are all of them). The only others are time spent collecting and the number of times collections have been done.

        I've also noticed what could be a saving on the Classpath side i.e. the memory bean could get its total heap and non-heap usage by summing pools. This is how it will be done in RVM, I'm thinking that might be a general solution for all and remove two VM methods

        Show
        Andrew John Hughes added a comment - I've succeeded in working out pretty much which and how many beans we need to represent MMTk. We map each MMTk Space to a JMX memory pool, while a single GarbageCollector bean (which also serves as a memory manager bean) represents the active MMTk plan. The pools are proving the most complicated to implement as they have the most functionality. Moreover, they require monitoring of events within the memory system that could affect performance. Fortunately many of them are optional, so even if we do implement them we could have them turned on only by a command line option in the same way that compiler timing is controlled. The functions basically come down to usage monitoring: current, peak and 'collection'. The first is easy enough because it just requires probing the pool on request. The others are more tricky as they require storing additional information. Peak usage seems an particularly tricky thing to monitor with regard to performance as it means we need to check the new usage levels each time something is allocated and see if we have a new peak. There is also a notion of thresholds for collection and normal usage, which again would require constant monitoring. We already seem to have a collection usage threshold, but it applies to the whole Plan as a whole and not the individual Spaces. These thresholds are however optional, unlike peak usage monitoring. So far, I've implemented all the fairly simple stuff (like current usage, pool type, etc.), so I just need to work out how to handle peak usage and whether we want to have (or already do have) support for the thresholds. The memory manager seems like it will be quite a bit simpler, mainly because there's only one of them! It also only contains four methods in total, and the ones for the general memory manager are trivial (it's always valid and its memory pools are all of them). The only others are time spent collecting and the number of times collections have been done. I've also noticed what could be a saving on the Classpath side i.e. the memory bean could get its total heap and non-heap usage by summing pools. This is how it will be done in RVM, I'm thinking that might be a general solution for all and remove two VM methods
        Hide
        Andrew John Hughes added a comment -

        The initial versions of all memory beans are now committed. We still need to work out how to handle usage monitoring.

        Show
        Andrew John Hughes added a comment - The initial versions of all memory beans are now committed. We still need to work out how to handle usage monitoring.
        Andrew John Hughes made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Andrew John Hughes logged work - 19/Aug/07 10:37 AM
        • Time Spent:
          2 weeks
           
          Initial versions complete.
        Andrew John Hughes made changes -
        Remaining Estimate 2 weeks [ 1209600 ] 0 minutes [ 0 ]
        Time Spent 2 weeks [ 1209600 ]
        Hide
        Ian Rogers added a comment -

        Any progress on this?

        Show
        Ian Rogers added a comment - Any progress on this?
        Hide
        Andrew John Hughes added a comment -

        IIRC, the patch (along with the other JMX ones) just needs to go on HEAD.

        I'll try and take a look this week.

        Show
        Andrew John Hughes added a comment - IIRC, the patch (along with the other JMX ones) just needs to go on HEAD. I'll try and take a look this week.
        David Grove made changes -
        Fix Version/s 1000 [ 14184 ]
        Hide
        Ian Rogers added a comment -

        Any pointers on this? I'd like to look at implementing other management beans. It'd be great to get the code into the head.

        Show
        Ian Rogers added a comment - Any pointers on this? I'd like to look at implementing other management beans. It'd be great to get the code into the head.
        Hide
        Erik Brangs added a comment -

        Removing assignees of all issues where the assignee has not contributed to Jikes RVM for quite some time or where the assignee is no longer a member of the core team.

        If you are affected and would like to work on one of the issues, please drop me a note (or change the assignee yourself if you have the necessary permissions).

        Show
        Erik Brangs added a comment - Removing assignees of all issues where the assignee has not contributed to Jikes RVM for quite some time or where the assignee is no longer a member of the core team. If you are affected and would like to work on one of the issues, please drop me a note (or change the assignee yourself if you have the necessary permissions).
        Erik Brangs made changes -
        Assignee Andrew John Hughes [ gnu_andrew ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Andrew John Hughes
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 2 weeks
              2w
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 2 weeks
              2w