Number: 2054

Date:  5-Sep-84 12':36':56

Submitter: Masinter

Source: Sheil, Kaplan

Subject: Tune array allocator parameters to minimize fragmentation

Assigned To: 

Attn: JonL, Kaplan

Status: Open

In/By: 

Problem Type: Performance

Impact: Moderate

Difficulty: Moderate

Frequency: Everytime

Priority: Hopefully

System: Language Support

Subsystem: Storage Formats/Mgt

Machine: 1132

Disk: 

Lisp Version:  4-Sep-84 19':45':00

Source Files: 

Microcode Version: 5124

Memory Size: 4096

File Server: 

Server Software Version: 

Disposition: 

Description: [spawned from AR#819]. Much performance tuning remains on the array allocator'
'
From': KAPLAN.pa'
Date': 24-Jul-84 21':33':57 PDT'
Subject': Array changes?'
To': Masinter'
'
If you are really going in to work on the bucket scheme, there are 2 other things that I think ought to be done':'
'
1.  Pick off the case where NCELLS=1 and GCTYPE=UNBOXED and give back a (CREATECELL \FIXP).  No use having all the extra overhead words and fragmentation due to such small blocks when there already exists an MDS type that will do just as well.'
'
2.  Change the allocator to traffic internaly in quad-word block sizes.  I.e., (FOLDHI NCELLS CELLSPERQUAD) to begin with, and adjust the various constants and macros to do \ADDBASE4 instead of \ADDBASE2.  This will mean that the quad-word alignment won''t have to be enforced, and also that hasharrays (also double pointer arrays) can be twice as long.'
'
Number 1 is easy and cost-free.  2 is harder, maybe not for this time around, but if you feel ambitious and want to help hashing...'
'
--Ron'


Workaround: 

Test Case: 

Edit-By: 

Edit-Date: