Summary: | unmuddle jobserver/nojobserver from encapsulated/unencapsulated | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Chapman Flack <ghost> |
Component: | PS Interpreter | Assignee: | Alex Cherepanov <alex> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | ||
Priority: | P3 | ||
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Customer: | Word Size: | --- |
Description
Chapman Flack
2005-09-24 13:06:54 UTC
Hmm, I just noticed this comment in pdf_main.ps: % It turns out that the PDF interpreter uses memory more % effectively if it is run under at least one level of save. % This is counter-intuitive, and we don't understand why it happens, Could it be because, at save level 0 with job server behavior, updates to global VM are being logged for unwinding? I wonder... I looked more closely at gs_init.ps and saw that the current situation is closer to what I'm suggesting than first I thought. It looks like it /is/ possible by the right combinations of JOBSERVER and NOOUTERSAVE to get three behaviors, encapsulated-job, unencapsulated-job, and not-quite-exactly-but-pretty-close-to-nojob: undefined defined JOBSERVER +-------------+-----------+ undefined | no job | encap job | |-------------+ | defined | unencap job | encap job | +-------------+-----------+ NOOUTERSAVE The no-job case is achieved sort of obliquely by taking a save and popping it, so the save level comes out 1 instead of 0 as it would likely be in a real no-job interpreter, but the effect is about right, logging of globals is disabled and no restore will ever touch them because the discarded save is unreachable. startjob (either true or false) does seem to fail in this case (probably because it can see there is a level-0 save, but doesn't have it to restore) and that's fine because startjob is supposed to fail and return false in a no-job interpreter. So maybe the actual current behavior is close enough, even if it was arrived at sort of sideways and the names JOBSERVER and NOOUTERSAVE were not quite the best choices (you leave off JOBSERVER to get a job server in unencapsulated mode). A purist might want the save level to be 0 in no-job mode, but at this point that would only trigger all the vmstatus pop pop 0 eq { save pop } if workarounds that people put in their code because of the old behavior. If the current behavior can be regarded as close enough, this report converts to a documentation bug for the places in the docs where the notions of encap-job, unencap-job, and non-job really are muddled up (-dJOBSERVER and -dNOOUTERSAVE in Use.htm especially). I'll suggest some rewording when I have something I'm happy with. Hmm, just had a tangential thought - if the GC determines that a save object has become unreachable, can it disable the logging of /local VM/ changes with respect to that object too? They'll never be needed and there could be a performance benefit. I haven't delved in the code to see if it already does something like that. Maybe there is a way to get clearer command parameters without having to break anything. gs_init.ps could check for -sJOBSERVER=ENCAPSULATED, UNENCAPSULATED, or NONE, with the same behavior as the current -dJOBSERVER (empty value), -dNOOUTERSAVE, or nothing, which could still be recognized and merely documented as deprecated. There's still the issue that JOBSERVER is also used elsewhere to enable special error handlers and the ^D Apple job separators, which right now means encapsulated jobs have these features, but unencapsulated jobs don't, unless you start them as encapsulated jobs and then do true (xyzzy) startjob, and then they do. so maybe this doesn't completely reduce to a doc bug. After 8 years with no activity, no specimen file and no apparent actual bug, I'm going to close this one. Any relevance to current Ghostscript is more than debatable. |