DLL Memory Handling - Revision history

Thomas Linder Puls: c'a

2008-01-19T21:21:44Z

c'a

← Older revision		Revision as of 23:21, 19 January 2008
Line 63:		Line 63:

	The reason that I assert pointers and not strings, is because otherwise the retract might retract a wrong string, because strings are retracted based on their value (i.e. the characters in the string). Pointers are also retracted based on their value, but their value is a memory address.		The reason that I assert pointers and not strings, is because otherwise the retract might retract a wrong string, because strings are retracted based on their value (i.e. the characters in the string). Pointers are also retracted based on their value, but their value is a memory address.

			[[Category:Memory Handling]]

Kari Rastas at 09:34, 3 October 2007

2007-10-03T09:34:31Z

← Older revision		Revision as of 11:34, 3 October 2007
Line 1:		Line 1:
	[[Heap]] memory that cross a DLL boundary should be handled with care, because the two sides may treat memory differently. In Visual Prolog a [[Garbage Collection\|garbage collector]] handles the heap.		[[Heap]] memory that cross a [[wikipedia::/Dynamic-link_library\|DLL]] boundary should be handled with care, because the two sides may treat memory differently. In Visual Prolog a [[Garbage Collection\|garbage collector]] handles the heap.

	== Vip/Vip ==		== Vip/Vip ==

Thomas Linder Puls: section about vip-to-vip handling

2007-09-08T23:22:49Z

section about vip-to-vip handling

← Older revision		Revision as of 01:22, 9 September 2007
Line 1:		Line 1:
	Visual Prolog ~~has~~ a garbage collector, ~~which reclaims~~ memory ~~when it is no longer in~~ use~~. However,~~ the garbage collector ~~does not know whether a Delphi program uses a piece~~ of ~~memory or not~~, and ~~therefore it may reclaim the~~ memory ~~even though the Delphi part of the program still needs it (most likely this will result in an access violation at some later point)~~.		[[Heap]] memory that cross a DLL boundary should be handled with care, because the two sides may treat memory differently. In Visual Prolog a [[Garbage Collection\|garbage collector]] handles the heap.

			== Vip/Vip ==

			When the caller and callee are both in Visual Prolog (and compiled with the same version of Visual Prolog), then memory can simply be passed back and forth as you wish, because both caller and callee will use the same garbage collector for the heap management. So in this case the DLL boundary is completely transparent.

			'''Notice''': If caller and callee are compiled with different version of Visual Prolog, then they are '''foreign''' to each other and memory must be handled accordingly.

			== Foreign/Vip ==

	~~Such problems~~ memory ~~always exist between exe~~ and ~~dll's~~. ~~And therefore~~ you must decide on a memory handling scheme. Basically there are two schemes to choose.		Visual Prolog's garbage collector does not know whether a foreign program uses a piece of memory or not, and therefore it may reclaim the memory even though the foreign part of the program still needs it (most likely this will result in an access violation at some later point). Therefore you must decide on a memory handling scheme. Basically there are two schemes to choose.

	== Caller provides memory ==		=== Caller provides memory ===

	This scheme is used in most Windows API calls and in most C/C++ context. The principle is that the caller allocates the memory and the callee copies the result into that memory.		This scheme is used in most Windows API calls and in most C/C++ context. The principle is that the caller allocates the memory and the callee copies the result into that memory.
Line 26:		Line 34:
	The last two lines in the clause should be turned into a separate predicate (in fact, it should ought to be in PFC already, but I can't seem to find it).		The last two lines in the clause should be turned into a separate predicate (in fact, it should ought to be in PFC already, but I can't seem to find it).

			=== Callee provides a clean-up routine ===
	== Callee ~~provices~~ a clean-up routine ==


	An alternative approach is to allow callee memory to float into the caller, and then give the caller a predicate to call once the memory should be released.		An alternative approach is to allow callee memory to float into the caller, and then give the caller a predicate to call once the memory should be released.

Line 50:		Line 56:
	getString() Result :-		getString() Result :-
	Result = "ResultString",		Result = "ResultString",
	assert(keepAlive(~~ucheckedConvert~~(pointer, Result))).		assert(keepAlive(uncheckedConvert(pointer, Result))).
	clauses		clauses
	releaseString(ToRelease) :-		releaseString(ToRelease) :-

Thomas Linder Puls: Copied from discussion forum (still in answer form)

2007-09-07T11:21:00Z

Copied from discussion forum (still in answer form)

New page

Visual Prolog has a garbage collector, which reclaims memory when it is no longer in use. However, the garbage collector does not know whether a Delphi program uses a piece of memory or not, and therefore it may reclaim the memory even though the Delphi part of the program still needs it (most likely this will result in an access violation at some later point).

Such problems memory always exist between exe and dll's. And therefore you must decide on a memory handling scheme. Basically there are two schemes to choose.

== Caller provides memory ==

This scheme is used in most Windows API calls and in most C/C++ context. The principle is that the caller allocates the memory and the callee copies the result into that memory.

In you getString case the vip declaration would look like this:
<vip>class dllExport
predicates
getString : (string ResultBuffer) language stdcall.
end class dllExport</vip>

Notice that the string parameter is an input argument. This is because the caller must provide a buffer for the result. (Very often there would also be another argument stating the size of the buffer, such that the DLL will not write outside the buffer).

The corresponding implementation could look like this:
<vip>implement dllExport
clauses
getString(Buffer) :-
Result = "ResultString",
ByteCount = sizeOfDomain(char) * (sting::length(Result)+1),
memory::copy(uncheckedConvert(pointer, Buffer), uncheckedConvert(pointer, Result), ByteCount).
end implement dllExport</vip>

The last two lines in the clause should be turned into a separate predicate (in fact, it should ought to be in PFC already, but I can't seem to find it).

== Callee provices a clean-up routine ==

An alternative approach is to allow callee memory to float into the caller, and then give the caller a predicate to call once the memory should be released.

In the getString example it could look like this:
<vip>class dllExport
predicates
getString : () -> string ResultBuffer language stdcall.
predicates
releaseString : (string ToRelease) language stdcall.
end class dllExport</vip>

In this case the caller will simply receive the string from the DLL, but once the caller is done with the string it must call releaseString to have it released.

In the implementation we have to make sure that the memory is not garbage collected until releaseString has been called. We can achieve this by asserting the string in a class fact and retract it when it is released, because memory that can be reached from a class fact is never garbage collected.

<vip>implement dllExport
class facts
keepAlive : (pointer ToKeepAlive).
clauses
getString() Result :-
Result = "ResultString",
assert(keepAlive(ucheckedConvert(pointer, Result))).
clauses
releaseString(ToRelease) :-
retractAll(keepAlive(uncheckedConvert(pointer, ToRelease))).
end implement dllExport</vip>

The reason that I assert pointers and not strings, is because otherwise the retract might retract a wrong string, because strings are retracted based on their value (i.e. the characters in the string). Pointers are also retracted based on their value, but their value is a memory address.