setting LFH (low fragmentation heap) on handles returned by getprocessheaps()

I don't know what are these heaps, but heaps don't have names,
AFAIK.


The one with the handle equal to the value returned by
`_get_heap_handle' CRT function.


Probably it has some features incopatible with LFH. For example,
it could be created with `HEAP_NO_SERIALIZE' flag, as mentioned in
MSDN.

Alex

setting LFH (low fragmentation heap) on handles returned by getprocessheaps()

I'm running this simple C program (see below, compiled with cl.exe
version 14.00, XP SP2) and see the following  output:

Number of heaps returned by GetProcessHeaps() = 4
Heap 0: Succeeded (1) setting LFH
Heap 1: Succeeded (1) setting LFH
Heap 2: Failed (0) setting LFH, error = 31
Heap 3: Succeeded (1) setting LFH

Q: What are these 4 heaps? Do they have names (and how can I get the
names)?

Q: Which one corresponds to the one used by malloc()?

Q: Why does Heap 2 fail?



int main()
{
HANDLE aHeap[101] ;
ULONG HeapFragValue = 2 ;
BOOL retval ;
DWORD ii, nHeaps ;

nHeaps =(int)GetProcessHeaps( 100, aHeap ) ;     printf( "\nNumber
of heaps returned by GetProcessHeaps() = %d", nHeaps ) ;
for ( ii = 0 ; ii < nHeaps ; ii++ )
{
retval = HeapSetInformation( aHeap[ii],
HeapCompatibilityInformation,
&HeapFragValue,
sizeof(HeapFragValue) ) ;
if ( retval != 0 )
{
printf( "\nHeap %d: Succeeded (%d) setting LFH",
ii, retval ) ;
}
else
{
printf( "\nHeap %d: Failed (%d) setting LFH, error
= %d", ii, retval, GetLastError() ) ;
}
}

return 0 ;
}

setting LFH (low fragmentation heap) on handles returned by getprocessheaps()

This is incorrect. HeapInformation = 0 does not automatically mean
that the heap is used by CRT. You should get CRT heap's handle by
calling `_get_heap_handle'.

Alex

setting LFH (low fragmentation heap) on handles returned by getprocessheaps()

Actually, I don't know whether there exists "standard" heap at
all. I think that CRT is free to choose a heap to use or to create
its own. I tried the code form this post:

http://groups.google.com/group/microsoft.public.win32.programmer.kernel/msg/b290154476a4425c

It reveals that there are at least two heaps with HeapInformation
= 0. One of them is indeed CRT heap.


I can't neither confirm nor refute that since I never heard about
this requirement. I always thought that CRT can use any heap it
sees fit.

Alex

setting LFH (low fragmentation heap) on handles returned by getprocessheaps()

HeapQueryInformation gives info about what the specific heap is. See
here - http://msdn2.microsoft.com/en-us/library/aa366703(VS.85).aspx
HeapInformation could be 0, 1 or 2. See details at the above page.


The standard heap (for which HeapInformation is 0) would be the one
where from you get the allocations, but I believe it depends on the
runtime to decide which one would be better from performance point of
view but I am sure of this. To allocate from specific heaps you would
make calls to HeapAlloc (and functions of that family).



To understand why heap 2 failed to set up as LFH, you would need to
know what heap that is and if setting it as LFH makes sense.

setting LFH (low fragmentation heap) on handles returned by getprocessheaps()

Actually, I missed a "not" before sure. :) Thanks for correcting me.
But, isn't the standard heap the one from which the allocations would
be done? I mean, one could change the heap info of standard heap to an
LFH but unless that is done, _get_heap_handle should return the same
heap as GetProcessHeap and that would be the same as the heap with HI
as 0 returned from GetProcessHeaps (considering heap info has not been
played around with). No?