On 13 Feb 2010, at 03:06, ABorka wrote:
gives the following error for make all (win xp 32bit)
Are you starting the compilation with FPC 2.4.0?
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am Samstag, 13. Februar 2010 11:15 schrieb Jonas Maebe:
On 13 Feb 2010, at 11:10, ABorka wrote:
My ppc386.exe is v2.5.1 compiled back in September
Building FPC svn trunk has always been and will always be only
supported when starting using the compiler the latest official
release (which is
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
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
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
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 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
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 atomic
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 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 the
Thanks Jonas, using 2.4.0 for the 1st compile worked.
I guess I shouldn't wait months before recompiling the latest SVN :)
On 2/13/2010 02:15, Jonas Maebe wrote:
On 13 Feb 2010, at 11:10, ABorka wrote:
My ppc386.exe is v2.5.1 compiled back in September
Building FPC svn trunk has always
On 13 Feb 2010, at 21:48, ABorka wrote:
Thanks Jonas, using 2.4.0 for the 1st compile worked.
I guess I shouldn't wait months before recompiling the latest SVN :)
Even if you subsequently recompile every new svn revision it may sometimes
suddenly not work anymore with your previously
In our previous episode, Jonas Maebe said:
Thanks Jonas, using 2.4.0 for the 1st compile worked.
I guess I shouldn't wait months before recompiling the latest SVN :)
Even if you subsequently recompile every new svn revision it may sometimes
suddenly not work anymore with your previously
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
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's
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
Hi Jonas,
As you can imagine I'd prefer to solve the $ifdef problem ;-)
To be honest: no, I can't imagine why you would prefer that. The entire
difference between $ifdef and $if is that $if checks the value of something
(and hence will give an error if the symbol is undefined) and $ifdef
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?
As for the negative numbers (possible overflow) from the heap status,
I logged a bug on that, with an example program, quite some time ago.
http://bugs.freepascal.org/view.php?id=14315
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely
19 matches
Mail list logo