thanks for all the comments!
the biggest problem with the initial commit (now patch) was that the impact of the jmx support was unknown in a default scenario where everything is disabled but there still is an impact on the core operations.
that is what I'm trying to figure out now, as the results of the tests were not clear.
to me performance with the stats enabled is not an issue in the first iteration, getting a good starting point is. I also needed to start pushing out code to be reviewed, as it piled up on my machine which in the end resulted in a huge commit, and then a huge headache
- 10% slower? where did you get the number from? the tests that I ran were inconclusive, see @stefan's comment
I agree with your observations, but it feels a bit like premature optimization until we actually get the code into JR core (currentTimeMillis vs nanoTime, BigDecimal vs double, locks vs volatile).
Yes, I'm refactoring to have just one bean (like a dynamic registry) enabled from the start, which would ideally be able to enable other jmx beans on demand.
I don't like the system property idea, as it kinda defeats the purpose of having jmx support ootb without a restart.
'slight interest' I should change the description at one point, the priorities constantly change, so should the issue description.
I also don't see the regression risk, we test constantly for performance degradation on the core parts, plus we'll disable everything ootb. the jmx support has a lot of benefits too, I'm sure in the end it will be worth it.
- I completely agree on the performance, I still need to run some tests, once we all agree on what the basis of the jmx support will look like (and where it will reside).
I'll concentrate on building a really low impact ootb jmx support (disabled and with a minimal footprint), then we can measure each component and optimize as needed.
As we appear to be having a vote for or against jmx support in general, I'll also send an email to the list, to gather some more info on this topic.