Analysis of Cas-obj

A place to record analysis and observations about the design represented by the Cas-obj prototype.

aspect	sub aspect	space/time tradeoff	alternatives	notes
Data Storage	Where: Each FS's storage is represented by values as part of 1 Java object can be GC'd No central CAS "Heap"	More space: always have Java cover object (vs possibility of no Java objects) Java cover object: 3 object overheads / FS (vs 1) Java cover object has denormalized shared additional fields Faster: locality of reference high.	for reduced space / FS could: avoid java object overheads for Obj & int arrays (but gives up GC by individual object) share cas ref, type ref, typesystem ref.	denormalized: each has cas ref, type ref, typesystem ref
Data Storage	"fs-id" - an int (dense) representing the unique ID of a FS. assigned lazily, not all FSs might have these not reused in case FS is garbage collected
Data Storage	Feature Structure representation: as 3 Java objects: array of Ints array of Objects container of above, with additional refs to cas typesystem type			cas ref is to one view; used for add/remove-indexes, getView, get the "fs-id"
Data Storage	get set of features some builtin hard-coded offsets some (e.g. SourceDocumentInformation) have extra int[] offsets (in each FS instance - probably needs to be shared )
Views
Indexes