DYLAN REQUIREMENTS
                               req.dylan
                               draft doc
                           richard 1996-10-02

INTRODUCTION


Scope

.scope: This document is intended to describe in a clear, concise, consistent, 
and unambiguous manner all significant aspects of the proposed memory manager 
(hereinafter referred to as the MM) to be supplied to the Dylan Group for 
integration with the Dylan development environment product and software created 
using that product.  .scope.sufficient: The document should contain enough 
information for the Memory Management Group to produce software that will 
satisfy the goals of this MM/Dylan relationship as set out in goal.dylan.

.scope.det: Not all the necessary details are present in this document.  They 
should, however, all fall under some heading here.

.scope.comms: This document will also serve as a medium for communication and 
negotiation  between the Dylan and MM Groups.


Conventions

.conv.req: Each requirement is tagged, and the following three lines contain a 
description, category, and source reference respectively.  Source references 
are in decreasing order of relevance.  Most descriptions are implicitly 
prefixed with "The Memory Manager shall...".

.conv.req.cat: Categories are used to determine priorities for work in 
planning, especially in contingency planning.  The categories are:

  critical: The requirement is critical to the project.  If the requirement
            is not met, the project can be said to have failed.

  essential: The requirement is essential and may not be omitted without
             renegotiating the requirements.

  optional: The requirement will be met if at all possible, but failure to
            meet it does not cause the project to fail.

  nice: Meeting the requirements is recognised as a "good thing" and will
        be attempted if the cost is low.

  unknown: The category of the requirement is unknown and needs to be resolved.


Background

.ref: Most requirements statements reference their source documentation.  The 
most important background materials are:

  - previous Dylan requirements meetings, meeting.dylan.*,
  - John Hotchkiss' message, mail.jh.1996-05-09.11-41,
  - Peter Benson's clarification of meeting.dylan.1996-07-16, 
mail.pabenson.1996-07-17.15-15.


Document History

.hist.1: The initial requirement list was brainstormed in early 1994 by Richard 
Brooksby and discussed at length with Tony Mann in particular.  At this point 
the effort to create a formal statement of requirements was abandoned due to 
lack of clear direction in the Dylan project.  MM development continued based 
on intuition and informal discussion.

.hist.2: The document was resurrected by Richard on 1996-07-16 in order to 
facilitate detailed Dylan planning.  An incomplete document was reconstructed, 
building on the experience of [redacted NB 2004-05-18].

.hist.3: The document was redrafted by Richard, starting on 1996-07-17, as a 
result of meeting.dylan.1996-07-16.  Richard examined every past Dylan meeting 
and a number of significant mail messages and attempted to tick off every point 
made.  The intention of this revision is to have it reviewed and approved by 
John Hotchkiss at meeting.dylan.1996-07-29.

.hist.4: Document was edited by drj, incorporated changes implied by 
meeting.dylan.1996-07-31, meeting.dylan.1996-07-29, 
mail.tony.1996-08-02.13-51.  No major changes, but much clarification.

.hist.5: 1996-10-02 drj.  Reworded .prot.obj.access as rit thought it unclear.

.hist.6: 1997-03-11 drj.  Misc changes

.hist.7: 1998-09-16 tony. Added a couple of requirements from 
meeting.dylan.1998-09-04(0). Clarified .dc.plat.nti4mv.

DEFINITIONS

.def.dw: "DW" refers to the Harlequin Dylan development environment product.

.def.mm: "MM" refers to the memory manager to be supplied.  The term includes 
non-software parts of the deliverable.

.def.obj: "Dylan object" refers to a Dylan language level object, formatted as 
described in design.dylan.container.

.def.code: "Dylan code" refers to non-MM code which was either compiled by the 
Dylan compiler or is part of the non-MM bits of the Dylan run-time system.

.def.reloc: To "relocate" an object is to change its memory address and 
therefore the bit-patterns of references to that object.

.def.recycle: To "recycle" an object or memory block means deallocate and 
possibly re-use the address space and storage occupied by that object or block, 
having determined that it is no longer required by the client code.

.def.root: A "root" is an object which is assumed to be alive by the MM.  Roots 
and objects which are reachable from roots (i.e. in the transitive closure of 
the "references" relation from a root) are never automatically recycled by the 
MM.

.def.work: Where it is stated that the MM must "work with" some other 
component, this means that the MM will function correctly and to requirements, 
and will not interfere with the operation of the other component such that it 
no longer meets its requirements.

.def.drm: DRM is the Dylan Reference Manual (see book.shalit95).

PRIORITIES

.prio: Where there is a conflict between requirements, or evolutionary 
deliverables are to be decided, the following priorities shall be considered in 
order:

.prio.1: reliability;

.prio.2: time to market;

.prio.3: size of Dylan applications;

.prio.4: performance (both throughput and latency);

.prio.5: portability;

.prio.6: adaptability to changing requirements;

.prio.7: flexibility to the user of the Dylan environment or a Dylan 
application.

Source: meeting.dylan.1995-08-29, modified by meeting.dylan.1995-08-31, further 
modified by meeting.dylan.1996-07-31.


FUNCTIONAL REQUIREMENTS


Allocation

.fun.obj.alloc: Allocate memory for Dylan objects (.def.obj).
  Category: Critical
  Source: (mail.richard.1994-09-22.13-38)

.fun.obj.recycle: Recycle memory occupied by unused Dylan objects 
(.def.recycle), expect as covered by other requirements .fun.obj.recycle.* 
below.
  Category: Critical
  Source: (mail.richard.1994-09-22.13-38)

.fun.obj.recycle.wrapper: Recycle memory occupied by unused dynamically 
allocated "wrappers" (design.dylan.container)
  Category: Nice
  Source: (mail.richard.1994-09-22.13-38) (mail.richard.1997-07-18.09-59)

.fun.obj.still: Allocate memory for Dylan objects which must not be relocated. 
(.def.reloc)
  Category: Essential
  Source: meeting.dylan.1996-07-16.reloc
[This requirement is wrong.  See request.dylan.170011.  richard 1997-07-07]

.fun.obj.stack-alloc: Allocate memory for Dylan objects (.def.obj) which are 
known to have stack-like lifetime patterns. The Dylan code will indicate when 
the "stack" is to be popped. The memory used by the objects popped from the 
stack will be recycled (.def.recycle), on the assumption that it is no longer 
required by the client code.
  Category: Essential
  Source: meeting.dylan.1998-09-04(0).stack-pool (mail.gts.1998-08-03.14-26(0))

.fun.obj.pin: Dylan code must be able to specify, after allocation and for a 
certain period, that an object must not be relocated.  The Dylan code will 
indicate explicitly when it can be relocated again.
  Category: Essential
  Source: meeting.dylan.1996-07-16.reloc

.fun.misc.alloc: Allocate general purpose, non-relocatable, memory blocks whose 
contents will not be intrepreted or recycled by the MM.  [a.k.a. "malloc and 
free"]
  Category: Essential
  Source: (mail.richard.1994-09-22.13-38)


Roots

.fun.root: Dylan code must be able to declare areas of memory to be considered 
as roots (.def.root).  .fun.root.gp: These areas will be drawn from general 
purpose memory (.fun.misc.alloc) or from memory not managed by the MM.  
.fun.root.dynamic: Dylan must be able to create and dynamically alter the set 
of roots at run-time.
  Category: Essential
  Source: meeting.dylan.1996-07-16.root

.fun.root.table: Support roots which are formatted as arrays of references.
  Category: Essential
  Source: meeting.dylan.1996-07-16.root

.fun.root.fmt: Support roots which are formatted as contiguous sets of Dylan 
objects.
  Category: Essential
  Source: meeting.dylan.1996-07-16.root

.fun.root.thread: Support roots which are part of the registers and stack of 
threads which have been declared to the MM.
  Category: Essential
  Source: meeting.dylan.1996-07-16.root


Measurement

.fun.measure.tools: Provide tools which allow the measurement of the MM's 
behaviour in order to optimize its parameters, or alternative, support the 
Dylan Group's development of such tools.  (See also .attr.tune.effort.)
  Category: Optional
  Source: meeting.dylan.1996-07-16.prof, 
meeting.dylan.1996-07-29.fun.measure.tools.


Validation

.fun.valid.if: Validate the parameters of calls to the MM from Dylan code.
  Category: Essential
  Source: meeting.dylan.1996-07-31.fun.valid

.fun.valid.obj: Validate Dylan objects.
  Category: Essential
  Source: meeting.dylan.1996-07-31.fun.valid


Weakness and Finalization

.fun.weak: Support the Dylan language-level implementation of weak references.
  Category: Essential
  Source: meeting.dylan.1996-07-16.weak-*.

.fun.weak.tables: Support the Dylan implementation of weak tables.  Tables are 
a mapping between a set of keys and a set of values.  Each set in the table is 
a vector.  In a weak table, one of the vectors is a weak object (therefore 
references the keys or values weakly).  When a weak reference to a key or value 
is deleted by the Memory Manager then the corresponding reference to a value or 
key in the other vector should be deleted by the Memory Manager as well.
  Category: Essential
  Source: meeting.dylan.1996-07-16.weak-tables, 
meeting.dylan.1997-02-27.weak.alloc

.fun.weak.index: Support dynamically-extensible integer-indexable arrays of 
weak references, which need not be Dylan objects.  [This is to support the 
Dylan debugger -- richard]
  Category: Essential
  Source: conversation between Richard and Tony, 1996-07-18 10:44 UTC, 
meeting.dylan.1996-07-16.weak-vectors

.fun.weak.slot: Support the Dylan implementation of weak slots efficiently.  
[That is, more efficiently than can be done using weak tables 
(.fun.weak.table).  This should have an associated attribute requirement 
specifying efficiency.  -- richard][The intent is to makes weak slot access 
about as fast as normal slot access] (see .attr.time.weak.slot)
  Category: Nice
  Source: meeting.dylan.1996-07-16.weak-slot

.fun.final: Support the Dylan language-level implementation of finalized 
objects: objects are registered, and are finalized in random order when they 
would otherwise have died.  Cycles are broken at random places.  There is no 
guarantee of promptness.  Registering an object N times will result in up to N 
finalization messages.
  Category: Essential
  Source: meeting.dylan.1996-07-25.postpone, meeting.dylan.1996-07-16.final, 
meeting.dylan.1996-07-29.fun.final, meeting.dylan.1997-02-27.final.multi

.fun.final-weak: A weak reference to an object will not prevent that object 
from being finalized if the object is registered for finalization.  Weak 
references will continue to refer to an object as long as that object is alive.
  Category: Unknown
  Source: none


ATTRIBUTE REQUIREMENTS


Test Suite

.attr.test-suite: The MM shall pass all tests in a test suite to be defined by 
the Dylan Group.  The test suite shall be specified as a set of Dylan programs 
to be executed, together with acceptable attributes: total run-time, time 
overhead, pause distribution, maximum space, space distribution, and failure 
rate (probably zero).  (see .counter.test-suite)
  Category: Essential
  Source: meeting.dylan.1995-08-31.accept


Control

.attr.control: Degree of control?

.attr.tune.effort: Provide performance tuning tools which will enable the Dylan 
developer to reduce heap size to comparable with ??? with ??? effort.  Customer 
should be able to see benefits within [??] hours.
  Category: Unknown
  Source: meeting.dylan.1995-08-29.leak, 
meeting.dylan.1996-07-29.attr.tune.effort


Capacity

.attr.capacity: The MM shall not impose a limit on the maximum amount of memory 
that can be allocated by the Dylan code, over and above that imposed by the 
operating environment and taking into account .attr.space.struct.
  Category: Essential
  Source: meeting.dylan.1996-07-31.attr.capacity

.attr.obj.max: The MM shall not impose a static limit on the size of Dylan 
objects.  A dynamic limit may be imposed by fragmentation.
  Category: Essential
  Source: meeting.dylan.1996-07-31.attr.obj.max


Debugging

.attr.debug: Debuggability?  Debugging memory management problems.  How long 
should it take?  Similar time-scale to .attr.tune.effort.
  Category: Unknown
  Source: meeting.dylan.1996-07-29.attr.debug

.attr.debug.find: Dylan programmers should be able to find references which 
point to otherwise dead data.  This process should take not longer than ?? 
minutes on average.
  Category: Essential
  Source: meeting.dylan.1996-07-31.attr.debug.find


Reliability

.attr.rel.mtbf: The MM shall have a mean time between failure of at least ???? 
hours.  The MTBF shall be such that failure during a particular week's use is 
"unlikely".  Dylan Group manager would not like to see more than 2 or 3 
problems due to memory management per year with a customer base of around 1000 
units.  A developer should be able to work for a month without memory 
management problems.
  Category: Essential
  Source: meeting.dylan.1995-08-31.dev, meeting.dylan.1996-07-31.attr.rel, 
meeting.dylan.1996-07-29.attr.rel.mtbf.

Acceptable levels of failure during early releases, beta, and delivery?
  Source: (meeting.dylan.1995-08-13.phase)


Adaptability

.attr.adapt: Meeting changing performance requirements.
  Category: Essential
  Source: meeting.dylan.1995-08-31


Timing Requirements

.attr.time.boot: During DW "boot up" the MM shall not use more than 5s of 
elapsed time (including initial root registration).
  Category: Essential
  Source: meeting.dylan.1996-07-31.attr.time.boot

.attr.time.pause.max: The Memory Manager shall not prevent DW from responding 
to a user action within 0.5s.
  Category: Essential
  Source: meeting.dylan.1995-08-24 (swm), 
meeting.dylan.1996-07-31.attr.time.pause.max.

.attr.time.hash.define: The MM shall impose an average overhead on defining a 
new entry in a pointer-hash table of less than 100 instructions per definition.
  Category: Essential
  Source: meeting.dylan.1997-07-02

.attr.time.hash.miss: The MM shall impose an average overhead on looking up an 
entry in a pointer-hash table of less than 100 instructions per missed lookup.
  Category: Essential
  Source: meeting.dylan.1997-07-02

.attr.time.thread.reg: Thread registration sequence shall be 50 instructions or 
fewer.
  Category: Unknown
  Source: meeting.dylan.1996-07-31.attr.time.thread.reg

.attr.time.thread.dereg: Thread deregistration sequence shall be 10 
instructions or fewer.
  Category: Unknown
  Source: meeting.dylan.1996-07-31.attr.time.thread.deref

.attr.time.ffi.in: The MM shall impose an average overhead on foreign code 
calling a Dylan function of 10 instructions or fewer per call.
  Category: Unknown
  Source: mail.pabenson.1996-07-17.15-15, meeting.dylan.1995-09-18.tramp.cost, 
meeting.dylan.1995-09-18.tramp.seh.cost, 
meeting.dylan.1996-07-31.attr.time.ffi.in.

.attr.time.ffi.out: The MM shall impose an average overhead on Dylan code 
calling a foreign function of 2 instructions or fewer per call.
  Category: Unknown
  Source: meeting.dylan.1996-07-31.attr.time.ffi.out.

.attr.time.weak.slot: The average overhead imposed by the MM on accessing a 
weak slot shall be no more than ???? instructions. (see also .fun.weak.slot)
  Category: Nice
  Source: meeting.dylan.1996-07-29.fun.weak.slot

.attr.time.misc.approx: In the absence of more accurate requirements for 
.attr.time.{hash.define, hash.apply, thread.reg, thread.dereg, ffi.in, ffi.out, 
weak.slot} it is required that they be comparable in cost to a function call.
  Category: Unknown
  Source: meeting.dylan.1996-07-29.attr.time

Space Requirements

.attr.space.boot: The total overhead [before any allocation is done -- rit 
1997-12-08], including the MM code, should [be] no more than 150Kb.
  Category: Unknown
  Source: meeting.dylan.1997-07-02, meeting.dylan.1996-07-31.attr.space.boot
  [ See also meeting.dylan.1997-12-15(0).  GavinM 1997-12-15 ]

.attr.space.struct: The structural overhead (i.e. over and above the memory 
occupied by actual objects) shall not exceed 10% [or the overhead specified in 
.attr.space.boot, whichever is the larger. rit 1997-12-08]
  Category: Unknown
  Source: meeting.dylan.1996-07-31.attr.space.struct

.attr.space.accuracy: ????  [Phrase in terms of dynamic utility?] [Compare with 
perfect, exact collector (ie space consumption over and above that accupied by 
reachable objects)]
  Category: Unknown
  Source: meeting.dylan.1996-07-29.attr.space.accuracy


Flexibility

.attr.flex: Flexibility to meet a range of end-user requirements (a variety of 
hardware configurations, transactions processing, user-interface code).
  Category: Essential
  Source: meeting.dylan.1996-07-31.attr.flex

DESIGN CONSTRAINTS


Environment

.dc.env.thread: Must work with native threads running Dylan or other language 
code.  See .def.work.
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.env.thread

.dc.env.multi.i4: Must work with a multi-processor architecture on 486/pentium
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.env.multi

.dc.env.multi.other: Must work with a multi-processor architecture on platforms 
other than 486/pentium (if we had any, which we don't)
  Category: Pointless ("nice")
  Source: meeting.dylan.1996-07-31.dc.env.multi

.dc.env.ambig: Must operate in the presence of "ambiguous roots".
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.env.ambig

.dc.env.gc: Must work with another, possibly foreign, memory manager, provided 
that the other memory manager is "friendly":

.dc.env.gc.boehm: Must work with the Boehm-Weiser conservative GC.
  Category: Optional
  Source: meeting.dylan.1997-07-02, meeting.dylan.1996-07-31.dc.env.gc

.dc.env.self: Must work with other instances of itself.
  Category: Essential
  Source: mail.pabenson.1996-07-17.15-15, meeting.dylan.1996-07-31.dc.env.self

.dc.env.malloc: The MM may not interfere with the system-provided 
implementation of malloc and free.
  Category: Essential
  Source: mail.pabenson.1996-07-17.15-15, 
meeting.dylan.1996-07-31.dc.env.malloc

.dc.env.hog: Must not hog process or system global resources, but keep them 
available for other components of processes.  [Is this an attribute?]
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.env.hog

.dc.env.odi: Must work with ODI ObjectStore.  [This requirement is "essential" 
because Dylan should work with ODI.  If it turns out to be impossible we must 
renegotiate these requirements. -- richard]
  Category: Unknown 
  Source: conversation between Richard and AndyS, 1996-07-18 11:13 UTC, 
meeting.dylan.1996-07-16.odi, meeting.dylan.1996-07-31.dc.env.odi. Category 
downgraded to unknown following mail.cliveh.1997-09-24.13-04 and subsequent 
mail.nick.1997-09-26.14-37 [nick 1997-09-26]

.dc.env.coop: Co-operate with other instances of the MPS in order to provide 
benefit to the user.
  Category: Nice
  Source: meeting.dylan.1996-07-16.product

.dc.env.load: Must operate when loaded and initialized into an existing process 
which is already running.
  Category: Essential
  Source: mail.pabenson.1996-07-17.15-15, meeting.dylan.1996-07-31.dc.env.load.



Linkage

.dc.link.object: The MM shall be supplied as a standard static linkable 
(library of object file) for the platform.  i.e. The MM shall not be linked 
dynamically with the Dylan code.
  Category: Essential
  Source: meeting.dylan.1996-07-16.library

.dc.link.single: The MM shall not require or cause the loading of other dynamic 
libraries.
  Category: Esential
  Source: meeting.dylan.1996-07-16.no-dll

.dc.link.c.header: The Memory Manager shall be delivered with ISO C header 
files which declare its interface.
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.link.c.header

.dc.link.c.macro: The Memory Manager interface headers may contain macros which 
can optionally be compiled into client code.
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.link.c.macro

.dc.link.no-crt: The Memory Manager shall not require standard C run-time 
support.  (See also ???? for counter-requirement.)
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.link.no-crt


Platforms

.dc.plat.nti4mv: Win32/Intel 486 or Pentium, linkable with the linker supplied 
with Visual C++ version 5.0. Must also be linkable with Visual C++ version 4.x, 
but the resultant executable need not contain debugging information.
  Category: Critical
  Source: meeting.dylan.1996-07-16.plat.i4, meeting.dylan.1995-08-29.win, 
(mail.tony.1998-07-28.16-21(0) & mail.daveb.1998-07-28.17-04(0))


Varieties

.dc.var.ro: An MM (see .dc.link.object) shall be delivered which does not 
contain validation code (see .fun.valid.*) or compiler debug information.
  Category: Essential
  Source: meeting.dylan.1996-07-31.dc.var.ro

.dc.var.dp: An MM (see .dc.link.object) shall be delivered which contains 
validation code [and compiler debug info?].
  Category Essential
  Source: meeting.dylan.1996-07-31.dc.var.dp


PROTOCOLS


Object Format

.prot.obj: Dylan object format?  As defined where?  Drop stretchy vectors? 
Wrappers can't move?  Don't impact performance of dispatch.  Lock objects for 
stretchy vector?  Locking for allocation (to avoid two-phase protocol)?
  Category: Critical
  Source: meeting.dylan.1997-07-02

.prot.obj.read: Support aligned read access to Dylan objects by threads which 
are registered with the MM.
  Category: Critical
  Source: meeting.dylan.1995-09-18.tramp.thread.reg

.prot.obj.write: Support aligned atomic udpate of Dylan objects by threads 
which are registered with the MM.
  Category: Critical
  Source: meeting.dylan.1995-09-18.tramp.thread.reg


Dylan Code Support

.prot.rehash: Support the use of pointer hashing, i.e., dependency on the bit 
pattern of a reference, provided that dependency is registered with the MM and 
can be invalidated by the MM.  Must be able to support the rehashing protocol 
described in the DRM.
  Category: Essential
  Source: meeting.dylan.1996-07-31.prot.rehash

.prot.debug: Support the the DW debugger.  Debugging protocol?
  Category: Essential
  Source: meeting.dylan.1996-07-31.prot.debug


FFI Support

.prot.ffi: FFI requirements.  Must be able to access "strings" from foreign 
code?  Lock objects down for FFI use?
  Category: Essential
  Source: meeting.dylan.1996-07-31.prot.ffi

.prot.ffi.exc: Exception handling mechanism must operate with the Dylan FFI and 
not interfere with foreign code.
  Category: Essential
  Source: meeting.dylan.1996-07-16.exc.foreign

.prot.ffi.access: Foreign code must be able to access certain Dylan objects 
transparently.  These objects may not contain references and must be nominated 
at allocation time.
  Category: Essential
  Source: mail.pabenson.1996-07-17.15-15, 
meeting.dylan.1995-09-18.c-direct-access.problem


Errors and Exceptions

.prot.abort: The MM shall never abort the process.
  Category: Essential
  Source: Conversation with Peter Benson, Tony Mann, Keith Playford, 
1996-07-23; mail.jh.1996-05-09.11-41 ("Graceful degradation"), 
meeting.dylan.1996-07-31.prot.abort.

.prot.stack-overflow: The MM shall not cause a stack overflow 
exception/condition/signal whilst a lock is claimed which would prevent the 
handler of such an exception (which may well be part of the client) from 
calling the MM.
  Category: Essential
  Source: meeting.dylan.1996-07-16.exc.stack, 
meeting.dylan.1996-07-31.prot.stack-overflow.

.prot.stack.declare: The MM shall declare to its clients how much stack space 
it requires in order to be called.  This is so that the client can arrange to 
have enough spare stack to run code of its own to handle a stack overflow 
exception _and_ call the MM.
  Category: Essential
  Source: Conversation with tony 1997-12-09

.prot.error: In the case of errors such as "Assertion protocol", "Program error 
protocol", "bus error".  The MM shall report to Dylan where possible, or call 
Dyaln run-time system.
  Category: Essential
  Source: meeting.dylan.1995-09-18.error, meeting.dylan.1996-07-31.prot.error.

.prot.exc.dylan: Exception handler code must integrate with Dylan exception 
handling mechanism.  (As specified where?) [need to work out exactly what this 
means]
  Category: Essential
  Source: meeting.dylan.1996-07-16.dc.env.thread, 
meeting.dylan.1996-07-16.exc.dylan, meeting.dylan.1996-07-29.prot.exc.dylan.

.prot.fail-alloc: The MM shall never fail to allocate (.fun.obj.alloc, 
.fun.misc.alloc) except under explicit instructions from Dylan code.
  Category: Essential
  Source: Conversation with Peter Benson, Tony Mann, Keith Playford, 
1996-07-23; mail.jh.1996-05-09.11-41 ("Graceful degradation"), 
meeting.dylan.1996-07-31.prot.fail-alloc.

.prot.consult: The MM shall never take an action that would result in failure 
to meet requirements .attr.time.* without first consulting Dylan code.  The 
actions offered shall include one which is no more than 10(?) times worse than 
the previous(?) action.
  Category: Essential
  Source: Conversation with Peter Benson, Tony Mann, Keith Playford, 
1996-07-23; mail.jh.1996-05-09.11-41 ("Graceful degradation"), 
meeting.dylan.1996-07-31.prot.consult.


PLANNING


Integration

.plan.int.effort: Effort required from the Dylan Group to integrate the MM into 
DW shall be less than one man week of good effort from a member of the Dylan 
Group.
  Category: Unknown
  Source: meeting.dylan.1996-07-31.plan.int.effort.

.plan.int.mm: MM effort?

.plan.int.dylan: Dylan effort?  Integration?  Maintenance of interface?  
Maintenance of object formats?  Maintenance of compiled code?  Maintenance of 
FFI?


Support

.plan.supp.use.init: After final delivery, the MM Group shall supply up to 3 
man-months of effort per year to debug and tune the MM, to train Dylan staff, 
and to assist with the use of the MM.
  Category: Essential
  Source: meeting.dylan.1996-07-31.plan.supp.use.init

.plan.support: Support?  Availability?  Probably from a migration of LISP 
support.  As of 1996-07-31 cannot be pinned down.
  Category: Unknown
  Source: meeting.dylan.1996-07-31.plan.support

.plan.avail.1: A problem in the MM which is preventing the Dylan Group from 
working will be given the full attention of one person from the MM Group until 
fixed or worked around.
  Category: Essential
  Source: meeting.dylan.1996-07-31.plan.avail.1

.plan.avail.2: A problem in the MM which is preventing a customer from working 
will be given an initial written response within 48 hours and a fix or 
workaround within one week.
  Category: Essential
  Source: meeting.dylan.1996-07-31.plan.avail.2-3-4

.plan.avail.3: A problem in the MM which annoys an external person (but for 
which there's a workaround or it's low-grade random) will be given an initial 
response within one week and fix or workaround by the next patch release of DW.
  Category: Essential
  Source: meeting.dylan.1996-07-31.plan.avail.2-3-4

.plan.avail.4: An infelicity in the MM (e.g. poor performance under certain 
circumstances) will be fixed by the next major release of DW.
  Category: Essential
  Source: meeting.dylan.1996-07-31.plan.avail.2-3-4

.plan.avail.categorize: The Dylan Group reserve the right to specify which of 
the above categories a problem falls into.
  Category: Unknown
  Source: meeting.dylan.1996-07-31.plan.avail.


Portability

.plan.port.fun: The MM must be functioning on a new platform (OS, architecture, 
and builder) with three calendar months notice.
  Category: Unknown
  Source: meeting.dylan.1995-08-29.plat.fun

.plan.port.full: The MM must meet all requirements on a new platform (OS, 
architecture, and builder) with six calendar months notice.
  Category: Unknown
  Source: meeting.dylan.1995-08-29.plat.perf


COUNTER-REQUIREMENTS

- Guarantee certain amount of manpower put into testing and integration.
- Guaranteed requirements reassessment.

.counter.feedback: Dylan Group guarentees a feedback of ??? somethingons per 
??? <timeperiod>.
  Category: Essential
  Source: meeting.dylan.1996-07-29.feedback

.counter.test.suite: Test suite development. (see .attr.test-suite)
  Category: Essential
  Source: meeting.dylan.1995-08-31.accept

.prot.thread.reg: Dylan code must register threads.
  Source: meeting.dylan.1995-09-18.tramp.thread.reg

.prot.thread.dereg: Dylan code must deregister threads.
  Category: Essential
  Source: meeting.dylan.1995-09-18.thread.term

.prot.obj.access: Certain memory (approximately speaking, that memory obtained 
from the MM collector) can only be accessed while inside a trampoline.
  Category: Essential
  Source: meeting.dylan.1995-09-18.tramp.access

.prot.tls: Dylan code may not store roots in Win32 "thread local store" (TLS). 
[This does not prevent using TLS to store pointers as long as that value is 
duplicated in an ambiguous route somewhere else]
  Category: Essential
  Source: meeting.dylan.1995-09-18.tls, meeting.dylan.1996-07-31.prot.tls.

.prot.atomic: Dylan may only update Dylan objects atomically, such that they 
are always in valid Dylan object format (.def.obj).
  Category: Essential
  Source: meeting.dylan.1995-09-18.atomic-update


ANTI-REQUIREMENTS

These are currently things that MM are not required to do.  This is for the 
avoidance of doubt.

.anti.i3: Support is _not_ required for the Intel i386.
  Category: Essential
  Source: meeting.dylan.1996-07-16.plat.i4.

.anti.real-time: The MM need not guarantee real-time data management (ie have a 
certain level of transaction throughput).
  Category: Essential
  Source: mail.jh.1996-05-09.11-41, meeting.dylan.1996-07-31.anti, 
meeting.1996-07-29.anti.real-time.


OPEN ISSUES

.open.fourth: Separation of third party (Dylan developer) and fourth party 
(application user) requirements (meeting.dylan.1995-08-31.fourth).  Note that 
fourth party requirements are unknown at the moment, but likely to emerge when 
Dylan has been shipped and is in use by customers.  MM Group should expect 
change (to requirements) as a result.
  Category: Unkown
  Source: meeting.dylan.1996-07-31.fourth