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 
Sub-task
In Progress
Major
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