[concurrency-interest] Thread priority

Gregg Wonderly gregg at cytetech.com
Thu Feb 7 23:15:32 EST 2013

On 2/7/2013 3:46 PM, oleksandr otenko wrote:
> Essentially, core dump, then boot the compiled classes and compiler state from
> it, discarding application state. :-)

Yes we used to do this in the previous century.  I think we've come far enough 
in our practices to do something that is much more flexible, tunable and not 
dependent on memory layout from the last run.


> Alex
> On 07/02/2013 17:55, Gregg Wonderly wrote:
>> 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
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list