high CPU utilization on STEP/RET

[Willem Grooters]

OpenVMS 8.3-1H1, Intergity rx2620; System has not been patched since installation.
PASCAL (using RDO), RdB:
@@2:WGR> pascal/vers
HP Pascal I64 V6.1-116 on OpenVMS I64 V8.3-1H1
@@2:WGR> rdo sho ver
Current version of RDO is: Oracle Rdb V7.2-200

It concerns an interactive program, using SMG 'windowing' under_the_hood. Main program and one module build sources /DEB/NOOPT, rest ob objects from library, built without debug.
The compilation strings used (for all modules) is:
PAS*CAL == "PASCAL/G_FLOATING/ALIGN=VAX/USAGE=NOVOLATILE/ENUM=BYTE"
G_FLOATING since that is a recommendation from the RMDL pre-compiler.
Linked execuatble using /DEB.
No warnings or worse have been issued in any step of image creation.

Run program, set breakpoint in module; on breakpoint: set mode screen, ^W to be able to step thrtough code. Now step/ret will cause excessive CPU utilization causing stalling other processes.
All database access has been executed before breakpoint; the program is wordking on an internal array (quite heavily and resursively).

Other debug actvities show no problem at all. It's just that STEP/RET causes this problem.

I won't rule out that bad allignment may be part of the problem, but I don't unerstand why that would be exposed so severely in step/return only.

Can this be explained - adn, if possible, solved?

[Volker Halle · Accepted solution]

Willem,

I think I can also reproduce this with a very small FORTRAN example. It seems to behave as expected on Alpha, but causes major CPU consumption on I64:

Program ITRC_1395846
CALL SUB
E N D
SUBROUTINE SUB
INTEGER*4 j /0/
DO I=1,100000000
J = j + 1
END DO
TYPE *,'J=',J
RETURN
E N D

I tried DBG> SET BR SUB and DBG> GO, then DBG> STEP/RET. It takes a little while (depending on CPU speed of Alpha) and then reaches the breakpoint at the RET.

If I run the same on OpenVMS I64, it uses vast amount of CPU (check with CTRL-T), before it finally reaches the RET breakpoint - it still hasn't, but I think it will...

Let me guess: the implementation of I64 may cause a trap after executing each instruction and check, whether the RET has been reached, whereas the implementation on Alpha may just 'know' where the RET is and set a breakpoint directly.

Volker.

[Volker Halle]

Willem,

if I look at the PCS (PC-sampling) data on the Itanium, most of the samples are in DEBUG.EXE, not in the original executing image. So my assumption about the implementation of STEP/RETURN on I64 may be right...

Volker.

[Volker Halle]

Willem,

to reduce the impact of this, just lower the priority of your process before starting to debug this piece of code with STEP/RETURN

Volker.

[Ian Miller.]

I wonder if this is related to the slower exception handling on I64?

[Willem Grooters]

Put it this way: the Itanium processor has its limitations where it comes to interruption handling - in general. Something to keep in mind....Lowering priority could be a workaround, in some cases. But wouldn't it be better if a real solution was offered?

[H.Becker]

>>> I wonder if this is related to the slower exception handling on I64?

Maybe, but unlikely: Volker would have reported to have seen PCs in LIBRTL.EXE or EXCEPTION.EXE.

[Hoff]

Itanium is a batch engine, offloading instruction scheduling and predictive tasks to the compilers, and to Ispike where it's available. The processor design goes through straight code very fast. Branches and calls, and exceptions and traps tend to hammer Itanium performance. And the debugger is close to the nadir of this design. Now whether HP can determine how to speed this particular debugger case, that's another question, and one that only HP can answer.

http://www.cgo.org/cgo2004/papers/01_82_luk_ck.pdf

[Volker Halle]

Willem,

an even better workaround would be to explicitly set a temporary breakpoint on the RETURN instruction source code line from this subroutine with:

DBG> SET BREAK/TEMP %line x

According to help, STEP/RETURN is the same as SET BREAK/TEMPORARY/RETURN;GO

It may be a simple problem of how this functionality has been implementated on Itanium.

Volker.

[Robert Gezelter]

Willem,

I, for one, would like to hear the results of whether there were large numbers of faults resulting from unaligned data.

While the DEBUGGER is admittedly a bad case for exceptions and branches, I would like to confirm that the problem is not correctable before settling for that conclusion. If the exceptions are for unaligned data, that is eminently correctable without a major redesign.

- Bob Gezelter, http://www.rlgsc.com