[Kaffe] core dump while running kaffe.
archie at whistle.com
Mon Mar 22 17:30:04 PST 1999
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
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
More information about the kaffe