[Kaffe] core dump while running kaffe.

[Archie Cobbs]

Godmar Back writes:
> > Godmar Back writes:
> > >  That wouldn't work with native threads or on an smp where disabling
> > > switches is impossible or very expensive.
> > 
> > So how are enterUnsafeRegion()/leaveUnsafeRegion(), which do exactly
> > this, going to work?
> 
> enter/leaveUnsafeRegion block signals for the current process, which has
> the side effect of preventing context switches that stem from asynchronous
> events such as time slice expiration, timer expiration, or I/O readiness
> in the uniprocessor, user-level jthread implementation.
> 
> Disabling signals does not have the effect of locking out other threads
> on a native thread implementation such as linux-threads, because the kernel
> schedules the threads in this case.  This has two consequences:
> 
> First, it means that we must use other means to stop other threads where
> this is necessary.  It is necessary when starting a gc.
> We use a signalling mechanism like Boehm's gc does.  It's a pain, it's
> expensive, and the current code in the CVS doesn't always work.
> Then again, the native thread implementation of the Linux JDK also 
> doesn't always work.  (Try running GCTest with it).

Exactly my point: enterUnsafeRegion() is broken on these other platforms.
The semantics should be "block other threads" not "block signals". It
should work independent of the underlying threads implementation.

But I see your point why we might not want to use enterUnsafeRegion() for
the utf8 locking problem (ie, it's slow).

> Second, using native threads means using thread-safe libraries.  There's 
> no need for enter/leaveUnsafeRegion as is when using our own user-level
> thread implementation.  This is so because we use jthreads in conjunction 
> with a C library that's unaware of this fact.

Right.. but we will still them when they are fixed, e.g. for JNI code.

So.. we need to do the following:

 (a) Fix/generalize enterUnsafeRegion() so it really works on all platforms
 (b) Fix the utf8 locking problem

If we do (a), then we can use it as a slow solution for (b) until
we come up with a different solution.

Digression.. almost any program that uses threads is going to need to
do mutex locking at some point. I can't imagine that the various threads
packages out there make this a horribly slow operation..?

Besides, can't we roll our own using machine-specific compare-and-swap
instructions?

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com