// // JDK Enhancement Proposal ("JEP") body template, v2.0 // // ==> Delete all lines starting with "//" // before entering a proposal into JBS // // Instances of this template are meant to be evolving documents. When // you initially draft a JEP you don't need to fill out every section of // the template, and in fact at that point you probably won't be able to // do so. As you get feedback and build consensus around your proposal // you'll revise the JEP accordingly. If your JEP is accepted and targeted // then you'll continue to revise it as the work progresses so that, once // it's complete, the JEP can serve as an authoritative record of what // was actually done. // // The body of a JEP uses the Markdown markup language // (http://daringfireball.net/projects/markdown/basics). // // All sections are optional except those marked REQUIRED. Keep sections // in the order shown below. If an optional section is not needed them // simply omit it rather than write soemthing like "None". Do not add // sections beyond those defined in the template. // // Use lines of dashes ("----") under section titles, not equals signs // ("===="). If you need subsections then use the "###" prefix before // subsection headings and "####" before sub-subsection headings. Do not // use HTML markup (
Add command line flag to influence the return value of Runtime.availableProcessors().
Runtime.availableProcessors() is used by many facilities in the JVM and in the JDK. Most commonly it is used to base thread counts on. By being able to change the return value, which currently is the physical CPU core count, system administrators can run multiple JVMs and/or other CPU intense components in parallel.
- Change code currently using Runtime.availableProcessors() to provide better pool sizing.
- Change how Runtime.availableProcessors() is implemented itself.
The value defined by the command line flag is used as return value of Runtime.availableProcessors()
// Why should this work be done? What are its benefits? Who's asking // for it? How does it compare to the competition, if any?
// REQUIRED -- Describe the enhancement in detail: Both what it is and, // to the extent understood, how you intend to implement it. Summarize, // at a high level, all of the interfaces you expect to modify or extend, // including Java APIs, command-line switches, library/JVM interfaces, // and file formats. Explain how failures in applications using this // enhancement will be diagnosed, both during development and in // production. Describe any open design issues. // // This section will evolve over time as the work progresses, ultimately // becoming the authoritative high-level description of the end result. // Include hyperlinks to additional documents as required.
// Did you consider any alternative approaches or technologies? If so // then please describe them here and explain why they were not chosen.
// What kinds of test development and execution will be required in order // to validate this enhancement, beyond the usual mandatory unit tests? // Be sure to list any special platform or hardware requirements.
// Describe any risks or assumptions that must be considered along with // this proposal. Could any plausible events derail this work, or even // render it unnecessary? If you have mitigation plans for the known // risks then please describe them.
// Describe all dependences that this JEP has on other JEPs, JBS issues, // components, products, or anything else. Dependences upon JEPs or JBS // issues should also be recorded as links in the JEP issue itself. // // Describe any JEPs that depend upon this JEP, and likewise make sure // they are linked to this issue in JBS.