This is the mail archive of the java-discuss@sources.redhat.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)


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?

Hans

> -----Original Message-----
> From: Jeff Sturm [mailto:jeff.sturm@appnet.com]
> Sent: Thursday, January 04, 2001 2:35 PM
> To: tromey@redhat.com
> Cc: java-discuss@sources.redhat.com
> Subject: Re: Precise GC (was Re: cannot build
> libjava/gnu/gcj/xlib/natClip.cc)
> 
> 
> 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
> jeff.sturm@commerceone.com
> 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]