home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / dylan / 118 < prev    next >
Encoding:
Text File  |  1993-01-22  |  1.5 KB  |  32 lines
  1. Newsgroups: comp.lang.dylan
  2. Path: sparky!uunet!brunix!cs.brown.edu!mhw
  3. From: mhw@cs.brown.edu (Mark Weaver)
  4. Subject: Re: Is GC really even necessary??
  5. In-Reply-To: barmar@think.com's message of 20 Jan 1993 17:11:48 GMT
  6. Message-ID: <MHW.93Jan21005548@cslab0a.cs.brown.edu>
  7. Sender: news@cs.brown.edu
  8. Organization: Department of Computer Science, Brown University
  9. References: <9301192202.AA18001@gensym.com> <9301192325.AA02857@af9hp.us.oracle.com>
  10.     <1jk14kINNeb@early-bird.think.com>
  11. Date: Thu, 21 Jan 1993 05:55:48 GMT
  12. Lines: 18
  13.  
  14. In article <1jk14kINNeb@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
  15. > In systems like Genera (the Symbolics Lisp Machine OS), these objects are
  16. > represented in OO fashion, with direct references to the data structures.
  17. > Therefore, the fact that they're collected in a linked list doesn't affect
  18. > the efficiency of accessing them.  This type of solution, where pointers to
  19. > kernel objects are passed in from user code, only works well on systems
  20. > with no kernel protection (like Genera) or with capabilities; otherwise,
  21. > user code could synthesize pointers to kernel memory that it shouldn't have
  22. > access to.
  23.  
  24. What is the problem with user code synthesizing pointers to kernel
  25. memory if there is hardware-level memory protection that prevents
  26. access to such memory?
  27. --
  28. --------------------------------------------------------------------
  29. Internet/CSnet: mhw@cs.brown.edu        | Mark Weaver
  30. BITNET: mhw@browncs.bitnet              | Box 2160, Brown University
  31. UUCP: uunet!brunix!mhw                  | Providence, RI 02912-2160
  32.