× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



With this feature, a garbage collector doesn't need to stop all the
other threads running in the common address space just to do an
inventory of unreferenced memory. GC can run all the time if needed.

Um, why not? It's still a pointer. Just because it can be passed between
processes (and even stored on disk, BTW, look at the SEPT) doesn't mean
it can be changed w/out effecting it.

Looking for unused references isn't even the hard part, it the heap
compaction. Say I've got memory laid out as:

1 2 3
123456789012345678901234567890123456789
xxxx xxxxxxxxxxxxx xxx xxxxxxxx

Where the x's represent different allocations. I've got 4 pointers to
those allocations, one points at memory-location 1, one at location 10,
one at location 26 and one at location 32. Yes, in the single-level
store model these aren't integer offsets from the beginning of a
process-space, rather they are universal offsets from the beginning of
memory (ok, actually segment and offset, but that doesn't matter) the
same principle applies, a pointer holds a reference to a place in
memory.

Given my example, I've got 11 bytes of "available" memory (the spots
w/out the 'x') but I couldn't allocate a 7-byte block as none of the
holes are 7-bytes long. I need to compact the heap. If I want to compact
the heap so all the allocations are together and I have an 11-byte hole
I need to move those allocations around. To move them around I need to
change the pointers that point to them, and to do that I need to
guarantee that the pointer is not going to be dereferenced as I'm moving
the data. To do that I need to pause all the threads. I don't see how
single level store or capability based addressing helps that.

-Walden

BTW, I believe only 64 of the bits are the memory address (was 48 on
CISC) and I have a recollection that it was admitted several releases
ago that the high-order bits aren't actually enforced in hardware
anymore, but what you describe is indeed the fortress Rochester model of
the i.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.