body { margin:0px; background-color:#fff } img { margin:0px; border-style:none } button { margin:0px; border-style:none; padding:0px; background-color:transparent; vertical-align:top } p:first-child { margin-top:0px } table { empty-cells:hide } .f-sp { font-size:1px; visibility:hidden } .f-lp { margin-bottom:0px } .f-x1 { } .f-x2 { } .f-x3 { } a:visited { color:#8b0000; text-decoration:underline } .capsub { color:#808080; font-weight:bold; text-transform:uppercase; letter-spacing:2.4px } .bulletlist { margin-left:0px; margin-right:0px; margin-top:0px; margin-bottom:0.1px } .style7 { color:#000; font-style:italic } .rightaligned { margin-left:0px; margin-right:0px; text-align:right; margin-top:0px; margin-bottom:0.1px } .footer { color:#808080; font-size:90% } .FWExtra { } .FWExtra a:link { text-decoration: none; } .FWExtra a:active { text-decoration: none; } .FWExtra a:visited { text-decoration: none; } .FWExtra a:hover { text-decoration: underline; } -->
Equi4 Softwaremetakit

top pages

 

Metakit
Tclkit
Starkit
CatFish

 

Soapbox

 

Blog
Musings
Tclers' Wiki
The SAX

Company

 

About
Services
Contact info
Support

 

Site map

memory mapped files

Modern operating systems support the mapping of files to virtual memory, "MMF" in short. The effect of MMF is that the entire contents of a file appears as in-memory.

Benefits:

  • access to data is through normal pointer indirection, i.s.o. reads/writes
  • there is no "current seek position", everything is random access
  • loading is "on demand", only actual accesses generate I/O requests
  • unused data is paged out (or even simply discarded, if unmodified)
  • there is no (repeat: NO!) allocated memory involved in using MMF's

Drawbacks:

  • growing files can only be dealt with by re-mapping a new memory area
  • there is no way to do asynchronous I/O, all loading is "blocking"
  • some O/S'es have bugs when writing from/underneath mmapped data

Metakit uses MMF's when the OS support it. This means that reading data files will take place without allocating any memory. Here are some comments to clarify the implications and to help separate fact from fiction:

  • fiction: Metakit is an "in-memory" database
  • fact: a little memory is allocated to manage views in datafiles
     
  • fiction: all data is read from disk when a datafile is opened
  • fact: data is read only when accessed, it is paged in per disk block
     
  • fiction: iterating over all data in a datafile requires lots of memory
  • fact: data is loaded as needed, and released when unused for a while
     
  • fiction: changes are written as they occur, and frozen with a commit
  • fact: changes are saved up in allocated buffers, and written on commit
     
  • fiction: changes are copied out to the memory mapped area
  • fact: Metakit uses regular write commands to save changes to file
     
  • fiction: all data is memory resident, and can easily be damaged by bugs
  • fact: the MMF is read-only, stray pointer writes cannot damage files
     
  • fiction: Metakit is not a real database, it simply loads and saves files
  • fact: Metakit loads on demand, and saves only changed data, securely

When MMF's are not available, Metakit will fall back to loading columns as needed, and releasing them on commit and rollback. In this case, Metakit will in fact revert to being a "gradually fully memory resident" database.

metakit index

• Intro / News

• Overview

• Documentation

• Licensing

• Download

• Mailing lists

• To-do list

• Acknowledgements

• Quotes

• Links

Copyright � 2007 Equi4 Software. Metakit is a trademark of Equi4 Software.