Number: 873

Date: 30-Apr-84 13':20':02

Submitter: Sannella.PA

Source: Masinter.pa

Subject: Want per-process global variables

Lisp Version: 

Description: '
Date': 15 Apr 84 18':17 PST'
From': Masinter.pa'
Subject': a design for process globals'
To': LispCore↑'
'
This is a proposal for a design for ''process globals'' which has the advantage that it has better performance characteristics for process switch and ''process global'' reference. There aren''t as many random variables bound. Its only disadvantages is that references to ''process globals'' no longer look like variable references (although that can be fixed in the compiler), and that it requires extra blocks of storage per active process (although the same space is currently allocated on the stack, which is a far more precious resource.) This requires no additional microcode or new opcodes etc.'
'
Here''s how it works': every process has a vector associated with it, its process-global-table.  PROCESS.GLOBAL.TABLE is a global variable; when a process switch happens, the scheduler resets PROCESS.GLOBAL.TABLE to the global table of the currently running process. There is a list PROCESS.GLOBAL.CORRESPONDENCE which maps from global name to global index. (PROCESS.GLOBAL.INDEX atm) returns the index for "atm". If "atm" isn''t already known, then a new slot gets allocated. This may cause every process-global-table in the world to get increased in size (requiring mapping down all active processes) but those are the breaks.'
'
Now, there are some macros, which turn references of the form'
(PROCESS.GLOBAL VAR) into the appropriate \GETBASEPTR, and references of the form (change (PROCESS.GLOBAL VAR) value)  (= into \RPLPTRs (which is like \PUTBASEPTR but it reference counts.)'
'
All of this stuff as far as I can go without building it into PROC is on [phylum]<lispcore>Misc>PROCESSGLOBAL.'
'
More could be done if we were willing to hack the loader and the compiler to resolve the LOADTIMECONSTANT in a more direct way  -- right now, (PROCESS.GLOBAL var) will turn into a sequence of bytecodes  GVAR(PROCESS.GLOBAL.TABLE) GCONST(offset) ADDBASE GETBASEPTR.N(0)  rather than the simpler GVAR(PROCESS.GLOBAL.TABLE) GETBASEPTR.N(offset). '
'
Comments appreciated.'
'
-----'
'
Date': 15 Apr 84 18':39 PST'
From': Masinter.pa'
Subject': Re': a design for process globals'
In-reply-to': Masinter.pa''s message of 15 Apr 84 18':17 PST'
To': Masinter.pa'
cc': LispCore↑.pa'
'
Actually, this will need a little more work to get it to work in the INIT case, since LOADTIMECONSTANT isn''t really handled for files that are loaded by MAKEINIT.'
'
The other downside of course is the requirement to edit every file that references any variable which is a ''process global''.'
'
There is a piece of (undocumented, and PLEASE don''t use this or tell anyone about it!) hackery in the compiler which is part of the CONSTANTS mechanism':'
'
The stuff I put into the compiler to handle CONSTANTS is in fact more general. The hash array COMPVARMACROHASH is used for a variable->form TRANSLATION.  (This also doesn''t work for SETQ, unfortunately, and would have to be extended, oops.)'
'
But, if you (PUTHASH ''FOO ''(PROCESS.GLOBAL FOO) COMPVARMACROHASH), then all references to FOO will instead compile into a reference to (PROCESS.GLOBAL FOO). '
'
If this were properly extended it would mean that we wouldn''t have to edit any of the functions that referenced any process globals, we''d just have to RECOMPILE them. '
'
How ''bout that?'
'
-----'
'
Date': 18 Apr 84 22':04 PST'
From': Kaplan.pa'
Subject': Re': a design for process globals'
In-reply-to': Masinter.pa''s message of 15 Apr 84 18':17 PST'
To': Masinter.pa'
cc': LispCore↑.pa, Sheil'
'
I think this is not too different in spirit from one of the suggestions that I made a year or so ago.  In my case, I suggested that the process global vector be defined by a DATATYPE or blockrecord record.  Your scheme has the advantage that globals can defined incrementally, as new exports are loaded into ABC, whereas my scheme would have required having in one place a single list of the variables.'
'
At the time I made my proposal, I remember that Beau had some observations on the nature of process globals and an alternative way of indexing them.  (I think it was something like a table associated with each variable that mapped from a process into the value of that variable for that process.  I don''t remember his arguments, but he should be consulted).'
'
Another suggestion I offered was something like binding process globals in a frame at the top of each process (as happens now, I think) except that a pointer to that frame would be kept in a special global variable (PROCESS.GLOBAL.FRAME ?) which would be reset on each process switch.  The GVAR and GVAR← opcodes would then basically act like free variable gets and sets, except that they would start their (microcode-assisted) searches on that special frame.'
'
Before we commit to a particular implementation, we probably ought to have some design discussions (meetings?) so that we get a clear understanding of the pros and cons of the various schemes.'
'
--Ron '
'
-----'
'
Date': 13 Jul 84 15':09 PDT'
From': Masinter.pa'
Subject': MAKEFILE performance'
To': Sheil, Kaplan, vanMelle'
cc': LispSupport'
'
15% of the time in MAKEFILE (at least) is going into looking up the NIL => current-output-stream.'
'
One more vote for fast process-globals.'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 10-Aug-84 15':19':47

Attn: Masinter, lisp

Assigned To: 

In/By: 

Disposition: 

System: Language Support

Subsystem: Microcode

Machine: 

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: Hard

Frequency: Everytime

Impact: Moderate

Priority: Hopefully

Status: Open

Problem Type: Performance

Source Files: