raskin@EE.ECN.PURDUE.EDU (Victor Raskin) (11/28/89)
While running some recursive, but fairly simple, functions on our Explorer 4.1 we have repeatedly run into PDL overflow problems. We have had to raise the PDL up to 20 times before we could successfully run our functions. We are planning to raise the PDL in order to avoid having to rely on the machine doing so. Has anybody run into the same kind of problems? Are there any risks involved in changing the PDL? Are there limits (inherent or practically recommendable)?
raghu@CS.UMD.EDU (Raghu Karinthi) (11/28/89)
We have had PDL overflow problem. May be because of the nature of applications we are using, we can get by by raising PDL only once. BTW, how do you raise the PDL? The way we have been doing it is by typing the RESUME key which basically is to continue with more PDL. Is it possible to specify a higher value of PDL right in the beginning? thanks Raghu
pf@islington-terrace.csc.ti.com (Paul Fuqua) (11/29/89)
Date: Monday, November 27, 1989 11:32pm (CST)
From: raskin at ee.ecn.purdue.edu (Victor Raskin)
Subject: PDL
Are there any risks involved in changing the PDL?
Are there limits (inherent or practically recommendable)?
There aren't any risks in changing the size of the PDL. There really
aren't any limits, aside from those limiting the size of any array
(since PDLs are just arrays of type ART-REG-PDL and ART-SPECIAL-PDL (the
former for argument/control stacks, the latter for special-variable
bindings)).
In fact, MAKE-STACK-GROUP and all its users, including MAKE-PROCESS and
PROCESS-RUN-FUNCTION, allow a :REGULAR-PDL-SIZE argument so you can
specify the sizes at creation time. You can also do it in the
init-forms of flavors built on TV:PROCESS-MIXIN. See page 6-13 in the
Window manual or the :init methods and daemons for ZWEI:ZMACS-FRAME and
W:LISTENER-MIXIN-INTERNAL.
There are times when you can't do that, for instance if you don't want
to run in a separate process. I ran into one of those situations a year
or so ago and did something I include below. It wraps a condition
handler around the offending piece of code that allows up to ten
automatically-grown pdl-overflows (controlled by a variable) before
signalling an error.
Within the body of the function, I have
(let ((overflow-count 0) ; Allow several automatically-handled pdl overflows.
(eh:*allow-pdl-grow-message* nil))
(condition-bind ((sys:pdl-overflow 'grow-pdl (locf overflow-count)))
<body code here>
))
and somewhere else (usually nearby) I define
(defparameter *pdl-overflow-count* 9)
(defun grow-pdl-handler (c n-loc)
(cond ((not (string= (symbol-name (send c :pdl-name)) "REGULAR"))
nil)
((>= (contents n-loc) *pdl-overflow-count*)
(setf (contents n-loc) 0)
nil)
(:else
(incf (contents n-loc))
:grow-pdl)))
The CONDITION-BIND sends control to GROW-PDL on pdl-overflow errors.
Binding EH:*ALLOW-PDL-GROW-MESSAGE* to NIL inhibits the "[Growing pdl to
N]" messages. The handler checks the symbol-name of the :PDL-NAME slot
of the signalled condition because I only want to handle regular-pdl
overflows (I've hardly ever seen special-pdl overflows), and some places
set the slot to :REGULAR and some to EH:REGULAR. I use a locative to a
local for the running count because in some perverse way it seems
cleaner than binding another special.
If the count is exceeded or the overflow is not in the regular PDL, the
handler returns NIL so the debugger will get it. Otherwise, it returns
:GROW-PDL, the proceed-type that is also used by the Resume key in the
debugger.
I hope this is of some use.
Paul Fuqua pf@csc.ti.com
{smu,texsun,cs.utexas.edu,rice}!ti-csl!pf
Texas Instruments Computer Science Center
PO Box 655474 MS 238, Dallas, Texas 75265Rice@SUMEX-AIM.STANFORD.EDU (James Rice) (11/29/89)
Yes, I have had similar problems. In case you don't know about it there's a programatic way of making sure that you grow the pdl you want, rather than pushing the resume key all of the time, called eh:require-pdl-room, which you call in the process whose pdls you want to grow. I've noticed two main causes for excessive PDL use. a) Running interpreted code. This may sound silly but it often requires 10X as much stack to interpret your code than to run it compiled. b) Not taking advantage of tail-recursion optimization. The TI compiler is pretty good at this but only if you (proclaim '(optimize (safety 0))) [!!!]. It is usually possible to recode simplistically written, non tail-recursive functions in a tail recursive manner. A good tactic to use is to break into your program as it runs and to look at which functions are on the stack (don't just use c-b, since this will not show all of the calls to the interpreter. It is usually the case that there are only a few offending functions taking up all of the room. These can usually be fixed up in some way. Rice.
Rice@SUMEX-AIM.STANFORD.EDU (James Rice) (11/29/89)
>> We have had PDL overflow problem. May be because of >> the nature of >> applications we are using, we can get by by raising >> PDL only once. BTW, how do you raise the PDL? The >> way we have been doing it is by typing the RESUME key >> which basically is to continue with more PDL. Is it >> possible to specify a higher value of PDL right in >> the beginning? >> thanks Raghu Further to my last reply: Yes, you can specify the PDL sizes of any new process you create, thus: (make-instance 'my-window-with-process-mixin :width <> :height <> :process '(My-Process-Top-Level-Function :special-pdl-size 4000 :regular-pdl-size 10000 ) ) or (make-process "My Process" :priority -1 :special-pdl-size 4000 :regular-pdl-size 10000 ) Rice.