Details

    • Type: Sub-task
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1000
    • Component/s: Runtime: JMX
    • Labels:
      None

      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.

        Gliffy Diagrams

          Attachments

            Activity

            dgrove David Grove created issue -
            Hide
            gnu_andrew 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
            gnu_andrew 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
            gnu_andrew 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
            gnu_andrew 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.
            Hide
            ianrogers Ian Rogers added a comment -

            Any progress on this?

            Show
            ianrogers Ian Rogers added a comment - Any progress on this?
            Hide
            gnu_andrew 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
            gnu_andrew 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.
            Hide
            ianrogers 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
            ianrogers 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
            ebrangs 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
            ebrangs 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).
            Hide
            ebrangs Erik Brangs added a comment -

            Merged Andrew's code in 5d5beff671776424a83d95f32ea25835d715485f. The changes will be in 3.1.4. Note that some of the operations relating to memory usage are still unsupported (see Andrew's comment above).

            Show
            ebrangs Erik Brangs added a comment - Merged Andrew's code in 5d5beff671776424a83d95f32ea25835d715485f . The changes will be in 3.1.4. Note that some of the operations relating to memory usage are still unsupported (see Andrew's comment above).
            dgrove David Grove made changes -
            Field Original Value New Value
            Workflow jira [ 17114 ] X10 Workflow [ 18296 ]
            dgrove David Grove made changes -
            Priority Major [ 6 ] Medium [ 3 ]
            ebrangs Erik Brangs made changes -
            Parent RVM-127 [ 13614 ]

              People

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

                Dates

                • Due:
                  Created:
                  Updated: