This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- To: Jeff Sturm <jsturm at detroit dot appnet dot com>
- Subject: Re: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- From: Cedric Berger <cedric at wireless-networks dot com>
- Date: Wed, 03 Jan 2001 21:35:28 -0800
- CC: Bryce McKinlay <bryce at albatross dot co dot nz>, jeff dot sturm at commerceone dot com, java-discuss at sources dot redhat dot com
- References: <Pine.LNX.4.10.10101040122570.14012-100000@cc42593-a.taylor1.mi.home.com>
Jeff Sturm wrote:
>
> On Wed, 3 Jan 2001, Cedric Berger wrote:
> > Yes, but it's been proven to be almost impossible to "written defensively"
> > this code. And there is a lot of such code. most of libgcj for example.
> > Is libgcj "written defensively" ?
>
> Not sure what you mean. But in our own code we do have many critical
> sections that perform some cleanup action. Try...finally blocks work well
> for this. (Note that the finally block is executed upon either
> InterruptedException or ThreadDeath, so hitting these with Thread.stop
> doesn't do any real harm.)
>
try {
sql.open()
sql.use()
} finally {
<<<--- For example here, A ThreadDeath() is thrown and abort the thing --->>>>
<<<--- are you protected against that? --->>>>
sql.close()
}
The problem of ThreadDeath is that he can appends anywhere,
anyplace, at any bytecode.
If the thread call, say "String.intern()" are you sure
that a ThreadDeath can come at any bytecode inside
String.intern() and leave the global structure intact?
If the thread call, say "new WeirdClass()" which trigger
classloading. Are you sure that a ThreadDeath() can occur
at any bytecode of the complex ClassLoading mechanism and
keep your VM intact?
Cedric