Date: Fri, 6 Feb 2004 09:12:27 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: John Polstra <jdp@polstra.com> Cc: freebsd-threads@freebsd.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext Message-ID: <Pine.BSF.4.21.0402060909510.24800-100000@InterJet.elischer.org> In-Reply-To: <XFMail.20040206085720.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Feb 2004, John Polstra wrote: > On 05-Feb-2004 Daniel Eischen wrote: > > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > >> Somehow the GC must see the registers of each suspended thread, so > >> that it can preserve any objects to which the registers point. > >> Presumably the thread context is stored in some region which the GC > >> treats as a root (e.g. on the thread stack, identified with > >> pthread_attr_get_np, as you say). > >> > >> A GC which has more information (e.g. the IP, the SP) may be able to > >> use more sophisticated techniques (by using compiler-generated object > >> liveness information, or by excluding dead areas of a stack segment > >> from consideration as roots). The limit of this is a system with > >> close-coupled compiler, thread system, and GC, which can do "precise > >> collection", including modifying the values of registers and stack > >> slots. > > > > I hear what you are saying, but it would seem that better > > designed software would avoid the issue by keeping track > > of any objects a thread has, using pthread_cleanup_push/pop, > > mutexes, etc. > > Maybe so, but that's not a useful attitude for an OS vendor to take. > An operating system is a provider of services. The services it > provides had better be generally useful, or people will make other > choices. > > Like it or not, a lot of GC systems these days are built on legacy > compilers (often GCC) that are not very malleable. They can't > easily be made to do the bookkeeping you're asking for. Or even if > they could do that, they call into legacy libraries (such as libc) > that were not compiled with such bookkeeping in mind. JDK is the > exception, not the rule. It is the way it is because Sun, IBM and > other companies have poured zillions of dollars into it. Dan sidestepped the question.. Of course you can find the saved state (registers) of all suspended threads. and there is an interface to suspend them as he showed.. but of course the layour of the registers is SUPPOSED to be private information (in this case known to the UTS and the kernel) > > If FreeBSD's native threads package can't provide a way to suspend > all threads except the GC thread and then read the registers of the > suspended threads, then the very widely-used Boehm conservative GC > package won't be usable with FreeBSD's native threads. Likewise, > those limitations would make it impossible to adapt Modula-3's threads > package to take advantage of FreeBSD native threads -- which would > be a big win performancewise. I'm sure there are plenty of other > examples. > > John > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0402060909510.24800-100000>