This is the mail archive of the
mailing list for the Java project.
RE: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- To: "'jeff dot sturm at commerceone dot com'" <jeff dot sturm at commerceone dot com>, tromey at redhat dot com
- Subject: RE: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Thu, 4 Jan 2001 15:01:46 -0800
- Cc: java-discuss at sources dot redhat dot com
Is it allowed to sometimes corrupt the runtime? If not, it seems to me that
we need to implement it so that delivery of the signal is blocked while in
many parts of the runtime, e.g. the allocator/collector, or the lock
implementation. That presumably means that these uninterruptable regions
would need to be described in a data structure somewhere, somehow? How
would you defer a stop call?.
How would you implement any of this? With a signal? Thread cancellation?
It also seems to me that this potentially has serious effects on instruction
scheduling etc. in the compiler, since every instruction can now generate
any exception, and the resulting state must correspond to some point in the
logical execution of the program?
> -----Original Message-----
> From: Jeff Sturm [mailto:firstname.lastname@example.org]
> Sent: Thursday, January 04, 2001 2:35 PM
> To: email@example.com
> Cc: firstname.lastname@example.org
> Subject: Re: Precise GC (was Re: cannot build
> Tom Tromey wrote:
> > If we can implement it without jumping through hoops, then
> it is fine
> > with me. If implementing it negatively distorts our thread
> > implementation, then maybe we shouldn't implement it.
> Seems to me that it once did work, though I could be imagining it.
> Top of Thread.java says:
> * Various methods which assume a VM are likewise unimplemented
> * We do implement stop() even though it is deprecated.
> which is clearly wrong.
> Jeff Sturm