| View previous topic :: View next topic |
| Author |
Message |
KennyT
Joined: 02 Aug 2005
Posts: 317
|
 Posted: Fri Jan 06, 2023 11:45 am Post subject: |
 |
|
hi, i've tried that and it seems to work in a "noddy" but not in my main application (but i'm still testing).
a question, does the number of bytes in the call to get memory have to be a multiple of 4/8/16?
K |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Fri Jan 06, 2023 12:04 pm Post subject: |
|
|
| No. The call is to GlobalAlloc and the memory allocation is guaranteed to be aligned on an 8-byte boundary. |
|
| Back to top |
|
|
Robert
Joined: 29 Nov 2006
Posts: 438
Location: Manchester
|
| Posted: Fri Jan 06, 2023 2:00 pm Post subject: |
|
|
| It is worth remembering that VirtualAlloc allocates (or uses memory) at page size granularity. So an alloc of a few bytes takes a full 4K page |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 317
|
| Posted: Fri Jan 06, 2023 4:40 pm Post subject: |
|
|
Seems to work well!
the memory "jumps" are much smaller than before.
the proof of the pudding is in the hands of our most rigorous user.
all being well, he shd be quite happy...
tks.
K |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 317
|
| Posted: Mon Jan 09, 2023 11:08 am Post subject: |
|
|
hi,
just following up...
you mentioned that this was only a 32-bit solution. what is the recommended equivalent 64-bit version?
K |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Mon Jan 09, 2023 11:32 am Post subject: |
|
|
Kenny
There are undocumented routines that you could use for 64 bits but you would have to provide your own interfaces.
Given time we could provide new routines that work constistently for both 32 and 64 bits. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 317
|
| Posted: Mon Jan 09, 2023 11:37 am Post subject: |
|
|
ok, if they're going to available by, say, end of Jan, that's OK.
if not, what are the C_External calls i would need to point to?
K |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Mon Jan 09, 2023 1:24 pm Post subject: |
|
|
Kenny
Here is a sample but you will need a new clearwin64.dll because __open_heap and __close_heap are not currently exported.
| Code: | c_external open_heap '__open_heap' ():INTEGER*8
c_external close_heap '__close_heap' (VAL4)
c_external heap_malloc '__heap_malloc'(VAL4,VAL4):INTEGER*8
c_external heap_free '__heap_free' (VAL4,VAL4)
integer*8 han,addr(10)
han = open_heap()
do i =1, 10
addr(i) = heap_malloc(han, 1000000)
write(*, "(Z8)") addr(i)
end do
do i =1,10
call heap_free(han,addr(i))
end do
call close_heap(han)
end |
I will see if new DLLs can be made generally available. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 317
|
| Posted: Mon Jan 09, 2023 6:26 pm Post subject: |
|
|
hmm, i spoke too soon!
i'm getting an "out of heap space" error under quite specific circumstances.
as far as i can tell there's plenty of memory available (committed figure is ~800Mb) and the failing request is only for 208 bytes.
if i send you the application installer and the datafiles that cause the issue, will you be able to take a look?
K |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 317
|
| Posted: Mon Jan 09, 2023 7:29 pm Post subject: |
|
|
following up...
the actual crash happens on a "write" statement, which, IIRC, means it's actually happened somewhere else and the write statement is the first time windows gets an opportunity to report the error...
K |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Mon Jan 09, 2023 7:34 pm Post subject: |
|
|
Kenny
Please see my personal message to you. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2505
Location: Sydney
|
| Posted: Tue Jan 10, 2023 12:30 pm Post subject: Re: |
|
|
| PaulLaidler wrote: | Kenny
Here is a sample but you will need a new clearwin64.dll because __open_heap and __close_heap are not currently exported. |
I am interested in aligning ALLOCATE on a page boundary, so I am wondering what the modified code might show. | Code: | c_external open_heap '__open_heap' ():INTEGER*8
c_external close_heap '__close_heap' (VAL4)
c_external heap_malloc '__heap_malloc'(VAL4,VAL4):INTEGER*8
c_external heap_free '__heap_free' (VAL4,VAL4)
integer*8 han,addr(10), page, offset
integer i
han = open_heap()
do i =1, 10
addr(i) = heap_malloc(han, 1000000)
page = addr(i)/4096
offset = addr(i) - page*4096
write(*, "(Z8,2i8)") addr(i), page, offset
end do
do i =10,1,-1
call heap_free(han,addr(i))
end do
call close_heap(han)
end |
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Tue Jan 10, 2023 12:54 pm Post subject: |
|
|
John
heap_malloc calls HeapAlloc and from the Microsoft documentation "The alignment of memory returned by HeapAlloc is MEMORY_ALLOCATION_ALIGNMENT".
This is 16 for 64 bit systems.
heap_malloc returns an address for allocated memory of user-given size which is unlike ALLOCATE which provides runtime memory for an object whose size is known to the compiler.
GET_GSTORAGE@ calls VirtualAlloc. Google "VirtualAlloc MSDN". |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Thu Jan 12, 2023 5:20 pm Post subject: |
|
|
I have encountered a problem which means that I will not be able to provide access to the new routines described above.
At the moment the general advice is to move to 64 bits as soon as possible and if an address for memory (off the heap) is required then call ALLOCATE for a CHARACTER array and then get its LOC.
p.s. Just to clarify. There are existing functions in the library (mentioned above) that currently require a user interface. These will continue to be available. Plans to provide direct access to these functions (without the need for a user interface) have been put on hold. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Fri Jan 13, 2023 9:57 am Post subject: |
|
|
Here is some code that illustrates how to get the address of a block of memory from the global heap using a call to ALLOCATE and FTN95.
| Code: | subroutine alloc(addr, size)
integer(7)::addr,size
character,pointer::arr(:)
ALLOCATE(arr(size))
if(ALLOCATED(arr))then
addr = loc(arr)
else
addr = 0
print*, "Allocate failed"
end if
end subroutine
subroutine dealloc(addr)
integer(7)::addr
character,pointer::arr(:)
ALLOCATE(arr(1), ABSOLUTE_ADDRESS=addr)
DEALLOCATE(arr) !Note: DEALLOCATE raises an exception on failure.
addr = 0
end subroutine
program main
integer(7) addr
call alloc(addr, 100000_7)
write(*,"(Z8)") addr
call dealloc(addr)
end program
|
p.s. It is better to use ASSOCIATED rather than ALLOCATED.
Last edited by PaulLaidler on Fri Jan 13, 2023 2:29 pm; edited 1 time in total |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
