[news.eclipse.platform] Re: Job.schedule( ) performance problem

[Danail Nachev <d.nachev@xxxxxxxxxx>]

Such analysis is definitely of interest, but the platform mail list or
bugzilla entry is more appropriate.

Randall Theobald wrote:
> I am a performance analyst for an adopting product and am analyzing high
> intermittent lock contention. One source of the contention appears to be
> from jobs scheduling themselves with a high frequency (which leads to
> the JobManager obtaining its global lock every time).
> 
> It seems that most of the calls to schedule() could be basically free if
> the schedule method only actually made the call to the JobManager if the
> job's getState method returns Job.NONE or Job.RUNNING.
> 
> I know that the Job.getState method's javadoc declares it to be
> inherently volatile, however, if the job's state was SLEEPING or WAITING
> "recently" (meaning when the return value was set, so it was definitely
> in this state after the client's request to schedule) we know that
> scheduling is pointless since the JobManager does nothing.
> 
> Does anyone see any problem with this approach? It would solve a lot of
> the strain on the Jobs locking. If not, I will go ahead and open a
> bugzilla for the issue.
> 
> 
>