Threads currently maintain a local list of ObjectMonitor objects which they provision from the global list. The stated reason for this construct is both to reduce contention on the global list mutex, and to reduce coherency traffic between monitors. Since JDK-8049737 removes the latter concern by padding out monitors, we only have the concern that we might see contention on the global mutex left, thus limiting the usefulness of having threads provision large chunks of monitors.

There's a compelling argument to make this tunable: By allowing user to set the number of monitors provisioned as low as to 1 would additionally be a worthwhile for applications tuned for low footprint overhead. Experiments have shown a reduction in footprint by 20-50MB on some setups of SPECjEnterprise2010 is manageable without a noticeable throughput or latency cost by reducing the MAXPRIVATE constant. Additionally the current options to limit the monitor population (-XX:MonitorBound=#) fails to take into account that a large proportion of the object monitors will be unused but held by threads on their local provisioning queue. This addition would work together with and not compete with -XX:MonitorBound for those users who wish to constrain the footprint overhead further.

In summary: There's a current limit of 1024 monitors provisioned per thread, with an implicit initial value of 32. I propose making these constants into flags, as well as reducing their default values from 1024 and 32 down to 256 and 8 to make JDK9 locking changes footprint neutral to end users without tuning.