Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

alt

Daniel Nashed

/LARGEADDRESSAWARE is needed for Domino 32bit on Win64

Daniel Nashed – 14 April 2009 08:11:24

Since 7.0.2 Domino is supported on Windows 2003 in 64bit and can leverage more than 2 GB memory for local + shared memory.
What is still not widely known among ISVs is that you need to link your applications with a new flag called /LARGEADDRESSAWARE.
Last week I spoke with one of the larger European business partners and they never came across this flag.

The flag allows a program to use more than 2 GB of memory (shared + local). Without this flag an application crashes when the 2 GB memory limit is reached.
Because Domino uses a lot of shared memory which is mapped to every server process it is very important that all C-API programs are linked with the /LARGEADDRESSAWARE flag.

The first application where shared + local process memory exceeding the 2 GB limit can crash your Domino Server!
We have also seen issues with Extension Managers without the flag causing issues and the original compile lines used by IBM (included in the cmp directory shipped with the current C-API toolkits) contain the flag for executables and also shared libs.

To have a 32bit application fully supported on Win64 you have to use the flag (see Microsoft --> reference).

Note that the 32bit sample makefiles in the current 8.5 C-API toolkit and some of the 64bit makefiles do not include the flags by mistake.
The cmp directory (maintained by core development) lists those flags correctly and you should include the flag in all your applications that should run in a Win64 environment.


-- Daniel
Comments

1Paul Gloomy  14.04.2009 17:08:44  /LARGEADDRESSAWARE is needed for Domino 32bit on Win64

Interesting article!

Is there any danger in running a server task having /LARGEADDRESSAWARE in a Win32 installation? Just to see if I can distribute the same .exe in both x64 and x86 environment (of course both will run Domino x86).

Thanks

2Daniel Nashed  14.04.2009 22:11:14  /LARGEADDRESSAWARE is needed for Domino 32bit on Win64

@Paul, since Domino 7.0.1 the Domino code has the /LARGEADDRESSAWARE flag set. This was done to support the /3GB switch which gives you 3 GB of RAM.

But that wasn't a good idea because the memory is emulated and you do not gain any performance.

Starting with 7.0.2 Domino supports to run on 64bit Windows which gives you a true 32bit address space per partition.

I see no problem if your code is already /LARGEADDRESSAWARE linked before that release but you will not gain anything.

What I did was adding the flag to all my makefiles when I switched to the newer compiler for Domino 7.

Domino 6 was using

Version 6.0 of Microsoft Visual C++ Development System for Windows

In Domino 7 you need

Microsoft Visual C++ .NET Version 2003 Development System for Windows

So when recompiling my applications I am adding this flag as part of reviewing the makefiles.

-- Daniel

3Paul Gloomy  15.04.2009 11:35:55  /LARGEADDRESSAWARE is needed for Domino 32bit on Win64

Why do I need "Microsoft Visual C++ .NET Version 2003 Development System for Windows" for my Domino 7?

I develop tools running in servers 8.5 x86 developed in VC++ 6 and there is no problem.

Here my problem is that I produce tools and users will use them in servers from R6 to R8.5 and I don't want to have two separate versions based on the server version (except if they use x86 or x64, of course). So that's why I was asking you if it would not harm using a server task being compiled with /LARGEADDRESSAWARE but in R6

4Daniel Nashed  15.04.2009 12:15:22  /LARGEADDRESSAWARE is needed for Domino 32bit on Win64

@Paul, I am not working for IBM so I cannot give you any official answer. It should be OK to use the /LARGEADDRESSAWARE also on older versions.

But at some point to have fully supported code you should use the recommended compiler. VC 6.0 also works on 7.x even that is not the certified compiler any more.

It is a best practice to use the same compiler IBM is using because you never know what breaks when using a different compiler.

On paper you are not supported if you use a different compiler but in most cases you are fine.

There are other platforms where a different compiler makes a big difference. For example on Linux you have to use the right compiler and libs else it does not properly work.

Linux ships with compat libs but you cannot us a too new compiler for a older Linux release.

But on Windows it "should" be OK. I am applying best practices when I can to be one the save side.

If you read the documentation in detail 7.x only mentions the newer .Net compiler.

In case you run into trouble you have to recompile with the fully supported compiler to get support.

By the way for 64bit development you need the Intel compiler because there have been issues with the Microsoft compiler at the time Domino 8.x was ported to 64bit.

Development is aware that this is painful for ISVs to get an extra compiler specially because you need the headers from the Microsoft compiler on top of the Intel compiler.

Not that I am happy about it but this is what is supported and I cannot help it.

If you are asking for an answer I will always try to give the full answer even you might not like it

Good luck with your recompiles and let me know if you find anything that breaks ;-)

-- Daniel

5Jérôme Deniau  15.04.2009 12:43:03  /LARGEADDRESSAWARE + Memory leak

I suspect also a memory leak on quite a lot of NSFDb functions in the samples

NSFDbOpen

NSFDbClose

Because I am lazy, I always use the samples first, the easiest one is the statdemo sample which kinda do nothing. I you watch carefully the system memory, it goes up and up every 10 minutes.

You can also test the addin sample, same stuff.

If you are lazier then me I do think you can find some compiled version of that @nsftools as far as I remember.

The memory (VM Size) seems to not go up too quickly, but Mem Usage does.

6Jessicabef  10.05.2009 17:20:20  privet

thans for the tip

Links

    Archives


    • [HCL Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]