Re: optimizeit: how to workaround/minimize wrong cput time in Object.wait()

From: Robert Klemme (bob.news_at_gmx.net)
Date: 11/09/04

  • Next message: Fahd: "Re: the best java tool on linux" 
    Date: Tue, 9 Nov 2004 17:44:23 +0100

    "NOBODY" <antispam@0.0.0.0> schrieb im Newsbeitrag
    news:Xns959C603609DE0nobodyantispam@207.35.177.135...
    > > Or it means, there are too many invocations of wait().
    > > You'd probably then want to switch from notifyAll() to notify(). Or
    > > you have a problem on the notifier side, for example with a farmer
    > > worker scenario where the farmer is too slow putting tasks into the
    > > task queue; then workers will starve and will wait most of the time.
    >
    > I already have separated writers semaphore and readers semaphore.
    > The writer notify() one blocked reader, reader notify() one blocked
    > writer. Works great. That was the fix I tried. But didn't change much
    the
    > profile.
    >
    >
    > >> it. What I want to determine is the real wait() %cpu due to real
    > >> contention to reaquire the monitor.
    > >
    > > So you don't want CPU time but wall clock time.
    >
    > I never want clock time. I already have monitored throughput of my code.

    Then are you satisfied with the throughput? If yes, why do you bother
    with the 70%?

    > A stackframe could be on wait() but actually the thread is done waiting
    > (waited, in JVMPI language) and tries to acquire the monitor.
    >
    > Would that part will be shown as cpu or not? Not documented. I supposed
    > yes because that would explain the 70% of time in wait() caused by
    > contention. I agree the cpu is not working for that thread though and I
    > shouldn't care, but...

    I did a small test where I increased overall wait time by sleeping before
    the notify and wait didn't even show up in the profiler results
    (with -Xrunhprof). Probably testing another profiler is best you can do
    at the moment.

    > But excessive contention (like you mentionned through notifyAll()) is
    > only detectable by guessing if the invocation count is to high, which
    > requires intrumentation mode, hence give a very biased result.
    >
    > So I don't know if I have high contention or if it is just a rounding
    > error! That's the whole problem.

    Since this seems to affect only one place in the code, did you consider
    instrumenting the code with measurements of your own? You could have a
    wait counter and a wait time counter and thus determine average wait time.
    Also, you might want to check average queue size (I assume you have a
    queue to transport the tasks or whatever it is).

    > I was planning to try other profilers. I guess this is inevitable.

    I'd start with "java -Xrunhprof". For me this gives quite good results
    and it's easy to use. You can use HPJmeter to view values or a tool named
    PerfAnal which you can find on sun's website. Both are free.

    Good luck!

        robert

  • Next message: Fahd: "Re: the best java tool on linux"

    Relevant Pages