andremussche / scalemm Goto Github PK

As long as the problem exists with interthreaded memory, ScaleMM can not be 
used in a productive environment. That is a big problem for me, because from 
the viewpoint of speed ScaleMM is really convincing. 

I made a test based on the simple thread demo of scaleMM3 with additional 
creating some interfacedobject (with reference counter). When sharing the 
interface pointer to another thread and free the object in context of this 
thread then ScaleMM fail with an exception (tested with ScaleMM2 and ScaleMM3). 
The same programm executing with the Delphi memory manager or with FastMM4 runs 
without problems.

Please clean up the code and made it threadsafe in case of interthreaded memory 
usage.

If you need more informations or an example then give me an feedback.

Regards
Maxx (DE)

Hello!

ScaleMM3.pas will not compile under XE4 Update1..

[dcc32 Warning] ScaleMM3.pas(1439): W1036 Variable 'iFree' might not have been 
initialized
[dcc32 Error] ScaleMM3.pas(1844): E2010 Incompatible types: 'NativeInt' and 
'NativeUInt'
[dcc32 Fatal Error] Project1.dpr(4): F2063 Could not compile used unit 
'Scalemm3.pas'

What steps will reproduce the problem?
1.Create a new empty Intraweb project using default options
2.Include ScaleMM2 as the first unit in your .DPR file
3.Build and run the application

There will be an Assert error:

Debugger Exception Notification
Project Project1.exe raised exception class EAssertionFailed with message 
'Assertion failure (...\smmGlobal.pas, line 264)'.

Extracted from smmGlobal.pas:

procedure TGlobalMemManager.FreeMediumBlockMemory(
  aBlockMem: PMediumBlockMemory);
var
  firstmem: PMediumHeader;
begin
  //keep max 10 blocks in buffer
  //if FFreeBlockCount >= 10 then
  begin
    firstmem := PMediumHeader( NativeUInt(aBlockMem) + SizeOf(TMediumBlockMemory));
    //is free mem?
    //if NativeUInt(firstmem.NextMem) > NativeUInt(1 shl 31) then
    if firstmem.Size and 1 <> 0 then
    begin
      //fully free mem? we can only release fully free mem (duh...)
      if PMediumHeaderExt(firstmem).ArrayPosition = 16 then
      begin
        //RELEASE TO WINDOWS
        VirtualFree(aBlockMem, 0 {all}, MEM_RELEASE);
        //exit!
        Exit;
      end;
    end;
    Assert(False);  <--- ERROR HERE
  end;

Using latest version from ScaleMM2 + BDS2006 + IW10 under WindowsXP SP3

What steps will reproduce the problem?
1. Open a new console application
2. Define Mat: Array of Array of Double;
3. SetLength(Mat, 100000000, 20)

What is the expected output? What do you see instead?
Program should load a little over 20Gb of RAM memory. It takes a couple seconds 
to load more than 20Gb on other MM. However, on ScaleMM, after reaching around 
20Gb, loading additional memory becomes incredibly slow (~1 additional Mb per 
second).

What version of the product are you using? On what operating system?
2.2

Please provide any additional information below.
I am running Delphi XE2, Win64, on a Dell Workstation (Intel Xeon, 12 cores, 
128Gb internal RAM).

What steps will reproduce the problem?
1. In XE2 64bits, create a new console application
2. Add ScaleMM2 to the top of the uses list
3. Add "WriteLn('test')" command (or anything else)

What is the expected output? What do you see instead?
The application should start and execute the command. Instead, it reports an 
exception short after initialization: "c0000005 ACCESS-VIOLATION"

What version of the product are you using? On what operating system?
Version 2.05 (19 March 2011)

Slightly modified to allow 64bits compilation. The following functions were 
modified:

Unit ScaleMM2:
- Integer/Cardinal parameters in Scale_GetMem, Scale_AllocMem and 
Scale_ReallocMem functions were replaced by NativeInt

Unit smmFunctions:
- replaced "dword" from CAS32 function to NativeUInt

ScaleMM2 works beautifully in XE2 32bits

I am running Delphi XE2 x32 application under Windows 7 x64 Ultimate. It uses a 
lot of multithreading and is quite CPU/RAM intensive. When it runs for an 
extended period of time, I notice that it slowly consumes more and more RAM. 
This does not happen when I use native Delphi memory manager, so I assume I 
don't have any own leaks (like created, but not deleted objects, etc.). It 
happens only when I use ScaleMM 2.4.1. I am fighting with this issue already 
for some time, I tried different solutions. Firstly, I thought that if I delete 
and recreate my threads from time to time (normally I create them only once and 
then use a pool of threads) it would help, because when the tread is destroyed, 
it will delete all its objects and free the memory. It didn't help, though, the 
memory is still leaking. Is there any method that can prove that this leakage 
is caused by ScaleMM, especially by fragmentation? Is there any way to to a 
"defragmentation"? Is there anything at all that can be done? Honestly, I don't 
want to go back to the default Delphi memory manager since with ScaleMM my 
application runs 4-5 times faster.

Thank you!

Testing a simple empty application with ScaleMM2 fails with MS application 
verifier. 
MS application verifier is important for Windows compability check and logo 
program.

Failure message is:

VERIFIER STOP 0000000000000013: pid 0x4D0: first chance access violation for 
current stack trace 

    000000007F688CF8 : Invalid address being accessed
    00000000004120AC : Code performing invalid access
    000000000008E9F0 : Exception record. Use .exr to display it.
    000000000008E500 : Context record. Use .cxr to display it.


program fails on line in ScalemMM2.pas:

function GetThreadMemManager: PThreadMemManager;
asm
{$IFDEF SCALE_INJECT_OFFSET}
  mov eax,123456789        // dummy value: calc once and inject at runtime
{$ELSE}
  mov eax,GOwnTlsOffset    // 2% slower, so we default use injected offset
{$ENDIF}
  mov ecx,fs:[$00000018]
  mov eax,[ecx+eax]      // +++ Fails here +++
  or eax,eax
  jz CreateMemoryManager
end;

Steps to reproduce:

Create empty Win32 Delphi application. Insert ScaleMM2 in first line of dpr.
Add program in Application verifier and choose basic tests (TLS test seems to 
be the test which fails) See screen shots

Best regards
Dirk

How to reproduce:
ScaleMM_v212.zip
Delphi 2010, scalemm.pas is the first unit in the application. Run the program, 
close it. Observe runtime error 216.

More details:
SysUtils has a class destructor for TEncoding, which kills any encodings 
created during the application run. Since they are created on first access, 
their memory resides in scalemm.
Class destructors run with the same priority finalization runs, and if ScaleMM 
relies on SysUtils then SysUtils is initialized before, and finalized after 
ScaleMM.

Suggested fix:
Just comment out SysUtils in smmGlobal.pas, nothing uses it anyway it seems.

Hi. 

I'm a Delphi programmer.
I use Windows XP x86 + Delphi 7 and Windows 7 x86 + Delphi XE5.
CPU: AMD Athlon(tm) II x2 3.2 GHz (x86, x86-64, MMX, 3DNow!, SSE, SSE2, SSE3)
Optimize.Move version: from ScaleMM 2.41

I recently found out about Optimize.Move and I liked it right away. It's so 
fast...
But later I found situations when it is a lot slower than the classic Move (on 
my processor).

For example:

var
   s: AnsiString; 
   ab: array of Byte; 

implementation 

procedure Test; 
var 
   i: Integer; 
   t: TTime; 
begin 
   SetLength(s, 10485780); 
   SetLength(ab, 1048578); 
   t := Now; 
   for i := 1 to 500 do 
   begin 
      Move(s[11], s[1], 10485760); 
      Move(ab[2], ab[1], 1048576); 
   end; 
   t := Now - t; 
   ShowMessage(FormatDateTime('ss.zzz', t)); 
end;

On Intel processors this code is only 1.08x faster when using Optimize.Move 
than the classic Move. 
On my processor I get ~10 sec with Optimize.Move and ~2.27 sec with classic 
Move. 
This kind of memory operations I use a lot in my code when deleting/resizing 
items from a custom string array. I could show you the code if you want. 

The original discussion about Optimize.Move and the problem: 
http://www.delphipages.com/forum/showthread.php?t=216340 

I hope these informations will help you track the problem easily. But, if you 
need more, I'm glad to help. 

Regards, 
David

What steps will reproduce the problem?
1. Try to compile scalemm2.12 on delphi 2007 :)

  Int16 = Smallint;
should be added to smmTypes for older delphi versions
or edit TSplitRecord in smmSmallMemory to not use Int16

What steps will reproduce the problem?
1. Try using the latest version (2.16) with Borland Delphi 7


What is the expected output? What do you see instead?

The compiler gives error : undeclared identifier : 'UIntPtr' on UINT_PTR  = 
System.UIntPtr;  // NativeUInt;

What version of the product are you using? On what operating system?

2.16

Please provide any additional information below.

I had to change the two files in the attachment to meke it works under delphi7. 
If you give me access to the repository I could push the commit ...

When creating TThread on 64 bit. I get exception at lock cmpxchg16b [r8] in

//either 8-byte or 16-byte CAS, depending on the platform; destination must be 
propely aligned (8- or 16-byte)
function CAS(const oldData: pointer; oldReference: NativeInt; newData: pointer;
  newReference: NativeInt; var destination): boolean; overload;

I thought ScaleMM2 was 64 bit ready?

What steps will reproduce the problem?
1. Install the library in the Delphi 7 IDE (Add source folder to environment 
variables of the IDE)
2. Try to use the Unit in a project written in Delphi/CLX

What is the expected output? What do you see instead?

The program should compile, while actually it doesn't compile giving could not 
compile unit ScaleMM2 unit .


What version of the product are you using? On what operating system?

Version : ScaleMM 2.15 
OS : Windows XP

Please provide any additional information below.

See the attached image for a screenshot of the error.

Compiler: Delphi XE2 + Upd3 (German version)
ScaleMM2: V2.13 SVN Rev 94

If I use the ScaleMM2 in EXE and (dynamical loaded) DLL I get an exception 
inside FreeLibraray. The order of shutdown the DLL seems to be wrong. I have 
the following order:
- EXE call FreeLibraray
- in DLL: DLL_PROCESS_DETACH - OK
- in DLL: Unit System calls "procedure FinalizeUnits;" - OK
  - FinalizeUnits call: unit ScaleMM2->finalization->ScaleMMUninstall;
  - FinalizeUnits call at last: unit System->finalization;
  - System->finalization call:
    {$IFDEF MSWINDOWS}
      FinalizeLocaleDate;
      if PreferredLanguagesOverride <> nil then
          FreeMem(PreferredLanguagesOverride);  -> EXCEPTION here!!!
    {Uninitialize the default memory manager, and free all memory allocated by this memory manager.}
      FinalizeMemoryManager;
    {$ENDIF MSWINDOWS}

I thing ScaleMM should shutdown inside FinalizeMemoryManager call.

  if GetHeapStatus.TotalAllocated <> 0 then
    Error(reAssertionFailed);  //Memory has been already been allocated with the RTL MM

NativeUInt is broken in Delphi 2009 (see: 
http://qc.embarcadero.com/wc/qcmain.aspx?d=71292)

I'm getting internal error:
[DCC Fatal Error] ScaleMM.pas(903): F2084 Internal Error: C12079

To fix it change ScaleMM.pas(110) to:
{$if CompilerVersion <= 20}
  type // from Delphi 6 up to Delphi 2007. Also for Delphi 2009 because of bug http://qc.embarcadero.com/wc/qcmain.aspx?d=71292
    NativeUInt = Cardinal;
    NativeInt  = Integer;
{$ifend}

ScaleMM3.pas cannot be compiled in XE4 because of 

TMemoryManagerEx
...
    AllocMem: function(Size: NativeInt): Pointer;
...
end;

size is NativeInt (signed)

I've attached simple patch, but I'm not sure it's proper, though it works for 
me.

How to reproduce:
- Try to compile scalemm on Delphi 2007.
[DCC Error] smmSmallMemory.pas(75): E2003 Undeclared identifier: 'Int16'

Suggested fix:
Add "Int16 = shortint;" after "NativeInt  = Integer;" in smmTypes.pas

What steps will reproduce the problem?
1. Set console application with 64-bit Windows compiler on Delphi XE2
2. Create an array with 8 or more threads of same type
3. Set the threads into an infinite loop (While True do)
4. Run!

What is the expected output? What do you see instead?
XE2 64bits there is a crash when the number of threads is equal to or higher 
than 8. In particularly, the Debugger notify the exception:
"C0000005 ACCESS_VIOLATION", and point line 231 of smmFunctions.pas (lock 
cmpxchg16b [r8])

The expected output, which is observed with Win32bit/ScaleMM or 
Win64bit/No-ScaleMM, is all processors running at full speed.


What version of the product are you using? On what operating system?
Windows 7 Ultimate, 64bit
Delphi XE2
ScaleMM_v215

Please provide any additional information below.
I am guessing it is something really stupid from my side, as I do not believe 
that a critical bug like that would not have been detected before. Anyway, I 
have been stuck with this bug for days now...

I would appreciate any help!

My system is a Dell Precision R5500, equipped with dual six-core Xeon 
processors, 64GB RAM.

What steps will reproduce the problem?
1. Just include ScaleMM2 first in "uses" list.

What is the expected output? What do you see instead?
For 64bit project with ScaleMM2, Debugging info lost in IDE (blue dots 
disappear), so breakpoints do not work. Also information on used variables, 
classes etc. lost, ANY information on source code didnt show.
Also, debug information isnt shown, when attaching to running 64bit project 
compiled with scalemm2.

What version of the product are you using? On what operating system?
Delphi XE2, only 64 bit version project. 
For 32-bit same project all works fine with ScaleMM2

What steps will reproduce the problem?
1. In a ISAPI library under IIS, for each web request make some memory 
consuming task like create TBitmap make some adjustment on it the send back in 
the response.
2. Load test it with JMeter
3. Allocated memory become more and more
4. after a while Out of system resources exception raised, and IIS recycle the 
app pool

What is the expected output? What do you see instead?
Expected to free all allocated memory.

What version of the product are you using? On what operating system?
I'm using 2.14 now, but I've checked with 2.05, 2.12 and with 3.0 also.

Please provide any additional information below.
I've checked my code with FastMM for memory leaks, and it didn't report any. 
I'm using Delphi XE2, and a multicore system.
Sometimes instead of "Out of system resources" I get "Cannot recieve data from 
font" or "Canvas does not allow drawing" messages as well. In the attachment 
you can find the cpu/mem usage in case of 35 concurrent users (WTM.jpg) and 
with 5 concurrent users (WTM2.jpg) and here's a stack trace of the error:

0198c49f ReportService.dll Vcl.Graphics                  OutOfResources
0198c542 ReportService.dll Vcl.Graphics                  GDIError
0198c573 ReportService.dll Vcl.Graphics                  GDICheck
01990cf3 ReportService.dll Vcl.Graphics                  CopyBitmap
019916d7 ReportService.dll Vcl.Graphics                  TBitmap.CopyImage
0199375f ReportService.dll Vcl.Graphics                  TBitmap.SetSize
01992fbf ReportService.dll Vcl.Graphics                  TBitmap.SetHeight

and 

0198c53b ReportService.dll Vcl.Graphics                  GDIError
0198c573 ReportService.dll Vcl.Graphics                  GDICheck
01990eab ReportService.dll Vcl.Graphics                  CopyBitmap
019916d7 ReportService.dll Vcl.Graphics                  TBitmap.CopyImage
01993245 ReportService.dll Vcl.Graphics                  TBitmap.SetPixelFormat

and


01a9ba28 ReportService.dll llpdfttfcodes                 TTTFData.TTFException
01a9a041 ReportService.dll llpdfttfcodes                 TTTFData.LoadTables
01a9a69f ReportService.dll llpdfttfcodes                 TTTFData.Create
01a9fbee ReportService.dll llPDFFont                     
TPDFTrueTypeUnicodeFont.Create
01aa14de ReportService.dll llPDFFont                     
TPDFFonts.GetUnicodeFont
01aa11f4 ReportService.dll llPDFFont                     TPDFFonts.GetFontByInfo
01ac44e9 ReportService.dll llPDFCanvas                   TPDFCanvas.ReceiveFont
01ac521d ReportService.dll llPDFCanvas                   
TPDFCanvas.SetCurrentFont
01ac76cc ReportService.dll llPDFCanvas                   
TPDFCanvas.UnicodeTextShow
01ac44ad ReportService.dll llPDFCanvas                   
TPDFCanvas.RawUnicodeTextOut
01ac6c87 ReportService.dll llPDFCanvas                   
TPDFCanvas.UnicodeTextOut
01ac7d23 ReportService.dll llPDFCanvas                   TPDFCanvas.TextOut