[concurrency-interest] Some interesting (confusing?) benchmark results
nathan.reynolds at oracle.com
Wed Feb 13 11:24:59 EST 2013
Alex on this list recently bumped into a problem. If all of the logical
cores are disabled except 1, then HotSpot will assume a uniprocessor
machine and enable all sorts of optimizations.
We also noticed some other issues. If the number of enabled cores
dynamically changes, then the number of GC threads doesn't adjust and
the heap layout doesn't account for the new NUMA characteristics. We
also wonder if fork-join framework can deal with the change and achieve
maximum throughput with the new configuration.
There are many layers of code which need to deal with core changes.
Having N threads do polling doesn't sound like a great idea. I like the
MBean event subscription idea. The JVM already should be checking and
when it detects a change, then it fires the MBean event. But, how do we
make sure all of the subscribers behave. What if the event thread gets
stuck inside one subscriber? The rest of the subscribers don't get the
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 2/13/2013 7:52 AM, Holger Hoffstätte wrote:
> I have to eat my words, at least some ;)
> On 13.02.2013 15:37, Holger Hoffstätte wrote:
>> On 13.02.2013 15:21, √iktor Ҡlang wrote:
>>> What's even more interesting is the the available processors can change
>>> at runtime, making it extremely hard to do anything interesting with the
>> Well..see towards the end of . However this approach is obviously
>> useless for Java, so you'd have to do something internal, like register
>> inotify callbacks on the /sys list or the like. Unfortunately that
>> doesn't work either . Things go downhill from there.
> So at least (just as the Javadocs say) periodically polling
> Runtime#availableProcessors() works fine - I just tried.
>> All statically wired thread pools (hi FJ) also suffer from this.
> This problem remains. Maybe the Runtime MBean could offer events so that
> individual subsystems can subscribe to them, and up/downscale appropriately.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest