Proposed addition of malloc_size_np()
andrew-freebsd at areilly.bpc-users.org
Tue Mar 28 10:57:25 UTC 2006
On Tue, Mar 28, 2006 at 12:39:06PM +0200, Poul-Henning Kamp wrote:
> Nope, not even close.
> What Recursiv did was novel in that the objects lived in hardware
> and microcode, there were no way to overrun an array, because you
> simply couldn't index it outside it's bounds. Not even in the
> operating system.
How is that different from all of the preceding segmented
machines like (to quote your .sig) the Z8001+MMU? (Or, later,
the i286). (Besides associating a type tag with the segment,
which is something that lisp and smalltalk machines did.)
> The fact that all objects were referenced by their object ID also
> meant that they could be put or moved anywhere convenient, with
> all references being by ID, it would be found when needed.
A segment ID doesn't seem to be too radically different from an
object ID. You can't access outside the bounds of the segment
on most segmented architectures, and you can put them or page
them wherever you like, because it's the segment descriptor that
tells you where in physical memory the segment is, not the
segment ID. Application code can't get to see that.
> It obviously comes with a significant performance penalty, not
> unlike page table lookups.
Amusingly, just as for SOAR, modern efforts covering most of the
same ground (JVM, .NET) are starting to show that you can do
better in software and simple hardware than you can with
complicated hardware. I'm not sure why that is still true in
this day where processor architects have more transistors than
they know what to do with...
More information about the freebsd-arch