On 4 Apr 2001 13:54:24 GMT, Joshua Marshall wrote: >Or stop-and-copy collectors in general, which don't need to touch >every object like mark-sweep collectors do. I really like the stop and copy collector theory, but they have practical disadvantages that significantly impact runtime performance. First, you need to perform a memory to memory copy of each object that is referenced. Because of this, a large amount of time is spent moving chunks of memory. On the other hand, you pretty much never need to worry about memory fragmentation. Second, references to objects *must* be doubly indirect. The reason is that an object's location can change at any moment in time. Fortunately, Intel CPUs have hardware support for this in the form of local and global descriptor tables. Unfortunately, *only* Intel CPUs offer support for this today, which means that it's not used in many operating systems. In fact, it's not being used at all in any OS designed after 1990, and Intel is eschewing support for segmentation in later generations of their CPUs (e.g., the IA-64). Pity. Segmentation is *very* useful when properly used to their advantage. As it is, the application itself must doubly-dereference object references, which incurs overhead when accessing the fields of objects. -- KC5TJA/6, DM13, QRP-L #1447 Samuel A. Falvo II Oceanside, CA
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4