As some of you have observed, z/XDC has gotten a bit sluggish over the years, and unfortunately, I have to agree. So identifying and correcting significan performance issues has become a priority for us.
In recent months, we have identified and corrected two major performance issues:
This performance hit occurred when z/XDC was running non-authorized. (It did not occur for programs running authorized.)
When z/XDC needs to examine user storage, one piece of information it needs to learn about is its storability, and for that z/XDC needs to issue a TPROT instruction. But unfortunately, TPROT is a privileged instruction. When running authorized, z/XDC can simply issue the TPROT directly. No problem.
But for non-authorized debugging sessions, z/XDC must call an authorized service to have the TPROT issued on its behalf.
Originally, we simply used our Service SVC routine to issue the TPROT, but the SVC overhead has turned out to be far greater than I ever realized!
So now, we’ve created a PC-invoked service to issue the TPROT, and I am astonished! The PC overhead is at least a thousand times faster than the SVC overhead! [Sure, I knew that SVCs were slow, but I had no idea that were that slow.]
However, PC routines need to be “owned” by an address space, so we put them into our Server Space. Consequently, the PC-implemented TPROT is available when XDCSRVER is up, but not when it’s down. [When the Server is down (and z/XDC is running non-authorized), z/XDC falls back to using the the SVC-implemented TPROT.]
So this has lead to a related change. Gradually, the Server Space has become central to more and more services (not just the performance issue described here). So now when the Server is down, we’ve added a block of warning messages (DBC496W) to alert the user that (among other things) performance might be slow and to ask him to ask Operations to bring the Server up.
The update that adds this support is named DBC-1808F. The starting point for more information is HELP WHATSNEW Z22 THINGSFIXED MAINTENANCE.
Recently, we found and corrected another major cause of performance problems. The degradation would occur when using the FORMAT command to display a mapped control block or data area in such a way that z/XDC’s internal disassembler was used. The disassembler would be used:
- When the map was built from SYM data,
- Or when it was built from ADATA and the OBJECT operand was used on the FORMAT or SET FORMAT commands.
The problem would not arise:
- When displaying unmapped storage,
- When displaying machine code,
- And when displaying data areas mapped by ADATA but under control of the FORMAT command’s SOURCE operand.
The problem arose because:
- Such maps tend to segment storage into 4-byte wide fields,
- And when z/XDC encountered such a field, it would wonder if its value happened to be the address of something interesting.
- And so it would go through a fairly expensive resolution process and automatically display the result as a comment.
If a map created a lot of 4-byte wide fields, the repeated resolutions could quickly add up to delays that could run to many seconds or even minutes! [Note, the CVT map is an example of a map that has a lot of 4-byte pointers.]
Unfortunately, the only way to decrease this performance hit was to remove the capability, so that is what FHC-1901A does. The starting point for more information is HELP WHATSNEW Z22 THINGSFIXED MAINTENANCE.