[concurrency-interest] Some interesting (confusing?) benchmark results

Nathan Reynolds 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 

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
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
>>> info.
>> Well..see towards the end of [1]. 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 [2]. 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.
> -h
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130213/9b643698/attachment.html>

More information about the Concurrency-interest mailing list