It does not seem "reasonable" that by default numprocessors is 1. This affects both GC (the level of GC parallelism is determined by numprocessors), and user applications since the user may introspect the available processors and limit concurrency accordingly.
I think we should do this for 3.1.2.
I have a patch ready for most of this.
Currently we use numProcessors, set by -Xrocessors=X for:
1) Setting the default number of collector threads
2) Returning an answer to java.lang.System.availableProcessors()
3) Choosing method sample sizes for various AOS components.
getting rid of -Xrocessors to avoid confusion
for 1), we will call sysNumProcessors once at the start to get the default, which is overridable using -X:gc:threads=
for 2), we will query sysNumProcessors for each call to availableProcessors, which will be overridable with a new -X:availableProcessors option
I am not sure what to do with 3 (or if what we currently do even makes sense from the switch from green threads)
re Daniel's patch. 1) and 2) seem right on to me.
For 3), we can probably do the obvious thing for now and just use the same value we use for java.lang.System.availableProcessors(). To the extent it made sense with green threads (somewhat dubious, but maybe defensible), the same argument would apply for physical processors. We're trying to adjust for getting multiple sames per timer tick because there is real parallelism in the underlying system.
Pushed as changeset -r 10421.
bulk close of all resolved issues in preparation for 3.1.3 release.