Re: The Hoard Scalable Memory Allocator

On Oct 16, 6:19 pm, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
<rani_shar...@xxxxxxxxxxx> wrote in message

news:1192564091.189188.202100@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





On Oct 14, 9:37 pm, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
<rani_shar...@xxxxxxxxxxx> wrote in message
On Oct 12, 6:35 am, "Chris Thomasson" <cris...@xxxxxxxxxxx> wrote:
________________________
- create a thread-local instance of a user-defined single-threaded
allocator in every thread (e.g., ms heap w/ HEAP_NO_SERIALIZE).

- allocation requests are forwarded to this thread-local user
allocator
directly.

What happens when a thread exits and there are still outstanding
allocations related to its heap?

Excellent question. This can be VERY important. For instance, I have
built
several single-threaded allocators that are entirely based on the memory
provided by their own stacks. The stack goes bye-bye when its parent
thread
exits! That scenario is handled by recognizing a specific condition that
indicates that other threads have references before it exits. If other
threads have references, it waits on a condition-variable.

Bounding the ref-counting (of outstanding allocations) to the thread
itself seems to be usage sensitive for which there might be use cases
in which threads are exhausted.
Don't you think that it makes more sense to bound the ref-counting to
the heap itself?

The only time I have to bind the counting to the thread is when a user
defined allocator depends on thread local sturcutres. I created an allocator
for it that is based on thread stacks, therefore its bound to the thread.

In that case you can even recycle "thread-less" heaps when new threads
are created and therefore to bound the number of heaps with the total
number of threads.
I'm referring to the HeapAlloc use case and not thread's stack that
you mentioned.

Bingo! I use exactly that for every but the per-stack allocator. You are
catching on to how my allocator works.

(not sure how you can accomplish that in portable and
reliable way).

I have to put vZOOM on Quadros OS for an ARM processor... The setup had no
heap! However, a Quadros task has some stack space... So, I simply created a
single threaded allocator per-task that used this space. I plugged it into
vZOOM via. single api call, and it worked. Bingo, they had a highly
scaleable heap out of thin air!- Hide quoted text -

- Show quoted text -

What is the point of creation and destruction of the per-thread heap?
There are case in which you don't control the creation and destruction
of threads (e.g. MS kernel32.dll thread-pool and thread from external
components calling my DLL).

Thanks,
Rani

.

Relevant Pages

  • Re: Error Raising and Memory in VB (general question)
    ... > object is terminated go out of scope, and the memory is also released. ... But why are you saying it uses stack? ... I think we are dealing with heap memory here. ... "COM's IMalloc allocator: ...
    (microsoft.public.vb.general.discussion)
  • Re: "Physical" memory bounds
    ... This gets tedious with discontiguous memory but I don't see ... is placed in the System Heap. ... Out of this, each task's stack is ... The dynamic memory allocator base allocator will use this label as the ...
    (comp.arch.embedded)
  • Re: P-Source: A Guide to the Apple Pascal System
    ... having a stack instead, but for Java that's not an option. ... heap regions. ... the heap allocator can force a collection if it needs more ... Activation frames will be allocated from these chunks until it is full, then allocate another chunk and link to it. ...
    (comp.sys.apple2)
  • Re: P-Source: A Guide to the Apple Pascal System
    ... around this problem by 'disposing' the dispose procedure and simply ... having a stack instead, but for Java that's not an option. ... A sliding boundary lets the heap breathe a little ... the heap allocator can force a collection if it needs more ...
    (comp.sys.apple2)
  • Re: unmanaged vs managed.
    ... Above article is based on what is found in SSCLI and does not reveal that much about the CLR memory manager's internals, nor does it include anything really useful about the GC and the JIT implementation in the commercial CLR product. ... Note that in following I denote by *Heap*, the "Heap Managers" heap, while with *GC-Heap* I denote the CLR managed heap. ... It's quite obvious that the CLR has it's own memory manager, after all the *GC-Heap* is THE CLR's private heap, no other component in the system uses/manages the GC-Heap but the CLR. ... The CLR Object Manager allocates from the GC-Heap, while the GC keeps the GC-Heap "clean" in close cooperation with the CLR Memory Allocator or an external Memory allocator like the one used when you run the CLR in the SQL Host. ...
    (microsoft.public.dotnet.languages.csharp)