16.02.2010 20:17, Nikolai Zhubr:
Ok. Would it be sufficient to only hook Getmem and Freemem?
From a brief look it seems other members (such as ReAllocMem) do not
modify the heap directly, so they need not be hooked I guess.
After some more reading and testing I think generally GetMem, FreeMem
16.02.2010 18:59, Jonas Maebe:
[...]
That would require separately maintaining a list of the memory managers
of all threads, which afaik does not exist currently.
Exactly! That's what I'd be happy with. I'll call it once per second
so a bit of slowdown wouldn't matter much. I think creating a c
On 16 Feb 2010, at 16:49, Nikolai Zhubr wrote:
16.02.2010 14:39, Michael Schnell:
On 02/13/2010 09:38 PM, Jonas Maebe wrote:
It would make the memory manager slower, and I don't think that
aggregating few statistics is a good reason to do so
Yep. But it should be possible to implement a fu
16.02.2010 14:39, Michael Schnell:
On 02/13/2010 09:38 PM, Jonas Maebe wrote:
It would make the memory manager slower, and I don't think that aggregating few
statistics is a good reason to do so
Yep. But it should be possible to implement a function that on request
(slowly) collects the list
On 02/13/2010 09:38 PM, Jonas Maebe wrote:
> It would make the memory manager slower, and I don't think that aggregating
> few statistics is a good reason to do so
>
Yep. But it should be possible to implement a function that on request
(slowly) collects the list of (or at last sum of) the sta
In our previous episode, Nikolai Zhubr said:
> after switching to FPC 2.4.0 I've noticed that:
>
> 1) GetHeapStatus.TotalAllocated does not seem to reflect size of
> allocations made by other threads anymore (I can provide a small
> example). I think such behaviour is not quite correct.
Afaik t
Nikolai Zhubr wrote:
Now, I'm starting to suspect that negative TotalAllocated values just
result from doing deallocations in a different thread, which is what my
programm actually does all the time. I'll go to make a small test.
Maybe it's related to (or the same as) bug 14315?
http://bugs.f
13.02.2010 16:33, Jonas Maebe:
2) GetHeapStatus.TotalAllocated sometimes return negative values, though I
haven't been able to prepare a reasonably small example yet (should I?)
Yes.
I haven't yet succeeded in reproducing negative values in a small
example, however I think the program below
14.02.2010 0:30, Jonas Maebe:
The heap manager is now separate per thread so it offers much better
performance.
Wait a minute. Is it then still legal for any thread to dispose heap blocks
allocated by another thread?
Yes, that's taken care of behind the scenes.
Ok. That is good.
Now, I'm st
On 13 Feb 2010, at 22:22, Nikolai Zhubr wrote:
> 13.02.2010 16:33, Jonas Maebe:
> [...]
>> The heap manager is now separate per thread so it offers much better
>> performance.
> Wait a minute. Is it then still legal for any thread to dispose heap blocks
> allocated by another thread?
Yes, that
13.02.2010 16:33, Jonas Maebe:
[...]
The heap manager is now separate per thread so it offers much better
performance.
Wait a minute. Is it then still legal for any thread to dispose heap
blocks allocated by another thread?
Nikolai
___
fpc-devel m
On 13 Feb 2010, at 21:21, Nikolai Zhubr wrote:
> 13.02.2010 22:51, Jonas Maebe:
> [trim]
>> Not without implementing a custom memory manager that does this or using
>> some OS function to obtain this information.
> So even some extra InterlockedExchangeAdd would be too expensive?
It would make
13.02.2010 22:51, Jonas Maebe:
[trim]
Not without implementing a custom memory manager that does this or using some
OS function to obtain this information.
So even some extra InterlockedExchangeAdd would be too expensive?
___
fpc-devel maillist -
On 13 Feb 2010, at 20:51, Nikolai Zhubr wrote:
> 13.02.2010 16:33, Jonas Maebe:
>> The heap manager is now separate per thread so it offers much better
>> performance. Keeping track of this information aggregated for all threads
>> would slow things down again (even if it would be done using at
13.02.2010 16:33, Jonas Maebe:
The heap manager is now separate per thread so it offers much better
performance. Keeping track of this information aggregated for all threads would
slow things down again (even if it would be done using atomic operations).
So it is indeed not possible to obtain g
On 13 Feb 2010, at 12:44, Nikolai Zhubr wrote:
> 1) GetHeapStatus.TotalAllocated does not seem to reflect size of allocations
> made by other threads anymore (I can provide a small example). I think such
> behaviour is not quite correct.
The heap manager is now separate per thread so it offers
13.02.2010 14:50, Vincent Snijders:
2) GetHeapStatus.TotalAllocated sometimes return negative values,
though I haven't been able to prepare a reasonably small example yet
(should I?)
Maybe that is caused by an overflow. So you need a long running example.
The program in question does not con
Nikolai Zhubr schreef:
Hello people,
2) GetHeapStatus.TotalAllocated sometimes return negative values, though
I haven't been able to prepare a reasonably small example yet (should I?)
Maybe that is caused by an overflow. So you need a long running example.
Vincent
_
Hello people,
after switching to FPC 2.4.0 I've noticed that:
1) GetHeapStatus.TotalAllocated does not seem to reflect size of
allocations made by other threads anymore (I can provide a small
example). I think such behaviour is not quite correct.
2) GetHeapStatus.TotalAllocated sometimes ret
19 matches
Mail list logo
