Default setting for numprocessors is 1. Probably should be all.


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.




December 22, 2011, 12:49 PM

I think we should do this for 3.1.2.

Daniel Frampton
January 16, 2012, 7:17 AM

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.

I propose:

  • 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)

January 16, 2012, 10:16 PM

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.

Daniel Frampton
January 17, 2012, 12:40 AM

Pushed as changeset -r 10421.

February 9, 2013, 10:50 PM

bulk close of all resolved issues in preparation for 3.1.3 release.


Daniel Frampton


Steve Blackburn



Fix versions

Affects versions