[concurrency-interest] Thread priority

Gregg Wonderly gregg at cytetech.com
Thu Feb 7 12:55:34 EST 2013

On 2/7/2013 10:30 AM, Nathan Reynolds wrote:
> How do we even collect that
> data?  We could run several tests and find the best value averaged for those
> tests, but there will always be a more optimal value for each individual
> application.  It seems this is something best for the program writer to tune.

I would say that using Preferences persistence would be perfectly acceptable. 
On the first application run, do it with 1000.  Get some data, and as you 
optimize methods, use the "numbers" to record what might work better.  I.e. if 
you instrument and then don't find any other odd things about "branch 
prediction" or some other metric, then record some indication to "optimize this 
early".  When the app starts up, go look in preferences, and use it to make some 
better choices.

Our computer systems are getting to be less and less worthy of hand holding and 
more and more capable of being "fully utilized" quickly.  Something which allows 
"history" to be recorded and used effectively would be great.

A documented API for developers to "pre-load" the optimization path would be 
awesome.  I can imagine being able to use the Jar manifest to provide some 
details about how code in a jar or packages in the jar, should be treated.

Many developers use profiling to find the "hot spots" and fix them up.  So, in 
the end, just "to-native" compilation should be all that needs to happen. 
Developers could indicate which "classes" and methods need specific 
instrumentation even, with javadoc like signatures.  Maybe even XML files stuck 
into a jar file, and pointed at by the manifest would be more flexible and tunable.

Gregg Wonderly

More information about the Concurrency-interest mailing list