Eclipse Community Forums: Eclipse Platform » Job.schedule( ) performance problem

Help

Home

Home » Eclipse Projects » Eclipse Platform » Job.schedule( ) performance problem

Show: Today's Messages :: Show Polls :: Message Navigator

Job.schedule( ) performance problem [message #333425]

Wed, 10 December 2008 17:32

Randall Theobald

Messages: 34
Registered: July 2009

Member

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.

Report message to a moderator

Re: Job.schedule( ) performance problem [message #333450 is a reply to message #333425]

Thu, 11 December 2008 17:02

Danail Nachev

Messages: 110
Registered: July 2009

Senior Member

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.
>
>
>

Report message to a moderator

Previous Topic:	[Databinding} Mess with tables/ Validation in structured Beans
Next Topic:	Managing fonts (for print-output)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 13:32:06 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter