[Vm-dev] linux thread priorities

John M McIntosh johnmci at smalltalkconsulting.com
Thu Feb 4 18:57:30 UTC 2010


On 2010-02-04, at 8:45 AM, Eliot Miranda wrote:

> There is no guarantee that checkForInterrupts is being called every millisecond.  There is only a guarantee that the VM will be asked to checkForInterrupts every millisecond.  It will actually check as soon as it next checks.  So if it is in a long-running primitive, or more importantly a full garbage collection it will check when this has finished.  The GC pauses are the killer.  For us every now and then there is a >100ms pause for GC and so the sound pump will occasionally be starved.

Well I have been doing some work for a client where we adjust the oops allocation counter GC trigger to float up/down based on the microsecond timer and a target millisecond time for an incremental GC. 

The full GC could be a special case where you have code in the GC loop  markAndTrace:.  Oh a counter and compare, technically that could be a free cost. Actually there *is* a counter in there....   statMarkCountLocal    Yes, yes it's a local that then is assigned to a global, because on powerpc it would become a register var, versus a memory access. Likely compilers today might just optimize it away.. 

Mmm you could pick some ceiling based on the variable object allocation count which is targeting a 1ms incremental GC cycle. 

The next hassle is the long running primitive calls.  But don't you have an audit list of them, how rare? If there is one or two, then can you be clever.. Or setup a timer interrupt or something just when the primitive is running? 


--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100204/e455cc2a/attachment-0001.htm


More information about the Vm-dev mailing list