forums.silverfrost.com

[KennyT]

hi,

I�m getting a return address of -1 from a call to:

CALL GET_GSTORAGE@ (IA, NB)

NB= ~80k (amongst other values) and has been successfully called multiple times previously - only ~1GB has been 'committed' by the application so there should be plenty of RAM available (it normally only �chokes� at ~ 2GB) and the system memory usage is less than 80%.

Is there some other condition that can cause this value to be returned?

K

[PaulLaidler]

Kenny

Is it a 32 bit or 64 bit application?

[KennyT]

32 bit...

K

[PaulLaidler]

The essence of GET_GSTORAGE@ is a call to VirtualAlloc(0, size, MEM_COMMIT, PAGE_READWRITE).

In this context size (NB) is a signed 32 bit integer so values up to 2GB should work. The only way for this routine to fail is when VirtualAlloc fails.

Memory is committed from the virtual address space, not the global heap.

Looking at the Microsoft documentation for VirtualAlloc, there is no indication that MEM_RESERVE is also required in this context i.e. where the base address in not specified (is NULL).

It is just possible that a change in the operating system has meant that MEM_RESERVE is now required but this seems unlikely.

[KennyT]

ok, tks.

i've reduced the number of calls to GET_GSTORAGE@ by setting the limit on its usage higher. previously, any request for memory > 16 bytes used GSTORAGE, <=16 used GET_STORAGE.

I've changed that decision to 256bytes and it seems better.

is there a recommended buffer size to decide which routine to call?

K

[PaulLaidler]

The documentation does not say anything about when to switch from GET_STORAGE@ to GET_GSTORAGE@.

Both of these routines get memory from the virtual address space.

If you prefer to get memory from the global heap (and don't want to use ALLOCATE) then you could use GET_STORAGE2@ (for a 32 bit application).

[KennyT]

hmmm,

get_storage2@ works twice (the first time it returns 2147...... (i.e. approx max int*4)) and then returns 0's thereafter...

K

[PaulLaidler]

Kenny

What is the context where you want to get memory? Maybe there is a more direct way.

[KennyT]

we make frequent use of memory addresses for storage of various data items, using two routines: vmget and vmfree. a typical situation is our dialogue handling code where we grab a number of addresses, pass them to generic field processing routines, then relaese the memory when the dialogue closes. this is legacy code and there is a LOT of it! at the moment vmget calls GET_*STORAGE@ and vmfree calls RETURN_*STORAGE@.

the only alternative i can think of is to do something like this, using a character buffer:

vmget calls ALLOCATE(ch(nb)) and passes back IAD = LOC(ch)
vmfree calls DEALLOCATE(ccore1(IAD))

which i will try now unless you can recommend something better...

K

edit: no, it doesn't work unless i keep a record in memory of all the allocated addresses and their size which is impractical, i think...

[PaulLaidler]

Using ALLOCATE and DEALLOCATE in this way seems like a useful work-around but we need a direct approach to allocating memory from the global heap such as that provided by get_storage2@ which works OK for me.

[KennyT]

is there an equivalent return_storage2@

K

[PaulLaidler]

Kenny

There is an equivalent and it is called return_storage1@ but, having tested it, I find that it is not working. However, you can provide your own interface...

[PaulLaidler]

Kenny

It is probably safer if you also use your own interface for get_storage...

[KennyT]

hmm,

it seems to only work partially, seems OK when all in same obj file.

but it looks like when the call to get_storage2 is in a DLL, it grabs about 60Mb memory (according to resmon) even if i've only requested 4 bytes! so my test prog soon runs out of gas.


K

MAIN:

[PaulLaidler]

Kenny

Try using your own interface for both routines, as in my last post.

The KIND=7 should be OK but remember that this is only for 32 bit applications.