Ozone Bug?

[William Uther <will+ozone-db@cs.cmu.edu>]

Hi,
  There is a bug, which I've pretty sure is in Ozone, that I'm having
trouble tracking down.

  I've attached the source for my project.  It is not particularly pretty
at the moment, but it shows the bug.

  The entrypoint for my test App is: will.sequiturDB.testApp

Test procedure:

  Start an Ozone server (with my stuff in the path).

  Start the test App.  It will ask you for a file.  Give it a text file a
few k long (I generally use one of the source files).  It will compress it
into the database and then finish - kill it once it disconnects from the
server.

  Now run the testApp again without restarting the Ozone server.  Add a
second file.  Note that things go ok.  Kill testApp when it is done.

  Now restart Ozone.  Run testApp a third time.  Note that Ozone seems to
freeze for a while, then throws a StackOverflowException.  This is the
problem.  Ozone shouldn't take that long.

Quick explanation of what the app is doing:

  I want to write a Version Control System that handles things as projects
rather than as files.  (see <http://www.xcf.berkeley.edu/~jmacd/prcs.html>
for the type of thing and how it differs from CVS.  I also want
client/server, which PRCS doesn't handle yet, and cross platform.)  This
project is the file store.  Think of it as doing a similar job to RCS.  It
is still in the early stages.

  The stored format is a grammar.  Any repeated structure, either within or
between files becomes a rule in the grammar.  (In fact the app will print
out its list of rules after adding a file.)  The algorithm to construct
this grammar has amortized linear time complexity, but when run in ozone is
a little slow.  I was originally going to try and compress byte by byte,
but it was too slow so I now compress line by line.  Change the boolean
"StoreImpl.useByteStrings" if you want to see the byte-by-byte speed.  This
might be an interesting optimization test case.

  Because all files are stored as one big grammar, the grammar could get
large - larger than available memory.  To handle this the grammar is stored
as a linked list of Ozone objects.  Parts of the grammar can be swapped in
and out of RAM by Ozone as required.  Unfortunately, the algorithm that
forms the grammar creates and destroys rules fairly frequently.  This seems
to be significantly slower for Ozone objects than for normal objects.

Anyway, if someone who knows more about ozone could take a quick look at
the reason for that large pause and StackOverflowException on restarted
Ozone server I'd appreciate it.  I think it might have something to do with
the Hashtables in digramStore.java - they can get rather large.  Hopefully
I'll be able to change those to odmg Maps soon anyway.

later,

\x/ill           :-}

SequiturDB.tar.arj