Robert,

> 
> FYI, I found the problem --- fstat is omitted from the
> Kaffe_SystemCallInterface. 
> 

> findInJar.c, which does not go through the syscall dispatch table (as
> I noted --- perhaps this should be fixed)

 I took the liberty to fix these two things in the current CVS repos.
I added fstat, and included jsyscall.h in findInJar.c

> 
> For the moment, I've kludged around the problem, but in the long run,
> it would probably best to add fstat to the tables.  (There are other
> cases where additional entries might be useful --- in particular,
> entries in the GC table for walkConservative and markObject, so that
> the stack-walking code doesn't need to call them directly, by name;

I think Tim's first priority was to make the VM independent of the
implementation of the gc and the threading, but he didn't see it as
a priority the other way round.  Thus, he calls functions in the VM
directly from the (internal implementations) of the gc and the threading.  

Similarly, the implementations of the subsystems are required to include
header files provided by the VM (threads.h, locks.h), but the VM does 
(or should not) include any header files local to the subsystems.  
Case in point: the pointers to mux and cv in locks.h are void *.
This is good as it allows separate compilation, but you pay a small
performance penalty for additional indirection.

Clearly, calling walkConservative and markObject from the threading
system violates encapsulation.   On the other hand, these two functions
are specific to the current mark-and-sweep collector; not that I say
that we will have a proliferation of different garbage collectors for
Kaffe in the near future, but I think a better solution might be to
require the threading system to provide an interface that allows
a caller to query the hot area of a suspended thread's stack so that
it can implement a conservative gc.

In the jthreads version, you'll notice that only internal.c depends
on VM internals.  I went to great lengths to be able to compile (and test)
jthread.c independently.  jthread.c does not know anything about 
Hjava_lang_Thread, for instance, which it simply treats as thread-specific 
data.  Ditto for markObject, gc_malloc, etc.
I have always felt that the division between internal.c and jthread.c, 
defined by the interface in jthread.h, might be closer to what the actual 
interface between VM and threading system should be.  

I believe the interfaces are not cast in stone, and if your NS port
shows good reasons for changes, these changes will be made.

However, we'll also have to consider what existing thread systems actually
provide.  I suspect that transvirtual probably looks at esoteric embedded 
thread systems for where they earn their money, such as pSOS.  

For what it's worth, I'm also working on a second implementation of the
threads interface, based on an in-house version of pthreads, which should
give us more data points.  The fact that it's an in-house version allows
me to extract the hot area for the conservative gc, a problem that is much
harder to solve for a generic pthreads implementation, as Dan Lambright
from the Open Group pointed out earlier on this list.  
While doing that, I also looked at some pthread packages, such as Provenzano's
that comes with libc_r in FreeBSD, and various Linux packages--the truth
is that it's a mess, and I haven't found one package that supports everything
I need.  Hardly anybody supports pthread_cancel properly, which is needed for
Thread.stop().   And I'm not even talking about the 3-4 versions of the
actual "standard" that fly around.

On a related note, I personally do not consider it mandatory that the 
interfaces actually take the form of a function pointer table, as is currently
the case.  It introduces a run-time overhead, and, compared to defining
interfaces in header files, I don't see where it helps encapsulation.
Tim said that of one the priorities is to be able to link a precompiled 
Kaffe VM with a precompiled threading system, again, I don't see how that
would be more enabled or less enabled by not using function pointer tables.

In addition, the practice of re#defining open, read, etc. seems somewhat
error-prone, as the fstat and findInJar.c bugs show.

> something that would be called when an iLock is destroyed, so that the
> lock package can free its own data structures; and possibly init

As far as I can tell, iLocks aren't destroyed.  They are reference-counted,
and if their ref count reaches zero, they are marked free and later reused 
within their address buckets.  So in the worst case, you'll have 64 unused 
native locks.

> entries which would be invoked before anything else, to avoid the
> somewhat tedious business of checking "initialized-yet" flags.  The

I think that's a good idea.

> lock business, in particular, is presently a pretty serious memory
> leak in my port).

In light of what I said above, what problems are you seeing?

> 
> On to figure out why the GC torture test exits without producing any
> output at all... (yes, yes, you start by uncommenting some of the
> print statements; however, given the nature of the thing, I have an
> unnatural fear that simply turning one of those on will eliminate a
> Heisenbug...). 
> 

 Yep.  That's what we found too.  You turn on printf and it works.

We used GCTest to find two bugs in gc-mem.c which were closely related
to the threading system.  You might want to look at the diffs between
the versions--maybe you're hitting similar things.

Finally, not wanting to get into a flame wars here or something:

> There is a chicken-and-egg problem here --- what rational person is
> going to *show up* at the bazaar if the most interesting merchandise
> is not on view?  (The most salient distinction between "cathedral" and
> "bazaar" models in that paper isn't the form of control of development
> --- Eric had final control of the contents of all fetchmail releases,
> and makes no bones about it --- but rather, the release of potentially
> interesting, buggy and incomplete code early).  And, on that cheery
> note...

 My comparison probably wasn't the best comparison--Eric didn't work on
fetchmail for a living (or did he?).  In Transvirtual's case, they have 
to set their priorities from a business point of view.  But I concur
that there is somewhat of a chicken-and-egg problem.

	- Godmar