1. RE: TK_mem problem and replacement
> -----Original Message-----
> From: jordah ferguson [mailto:jorfergie03 at yahoo.com]
> B4, you read this, i have written a tk_mem.e replacement but
> using pure
> euphoria code. It is fast and is still undergoing a series of
> tests. It
> is safer and faster than the original tk_mem. Soon to be
> released on RDS
One of the reasons tk_mem was written was to use the memory management of
windows, which has the capability to return RAM to the OS when you're done
with it.
> -- What if you are allocating a Byte,Strz or Word? They would still be
> -- forced to take 4 bytes of memory with below code
You're going to always allocate 4 bytes (even if you only ask for 1).
Everything is 4-byte aligned.
> If Yes, pData should be a minimum of 4 Bytes. Why bother with
>
> if pData != 0 then
> pData = vSizeLengs[pData]
> end if
Here, pData is originally an index into vSizeLengs. Derek then makes sure
that you're asking for at least 4 bytes (you might have wanted more). I
suspect that he's left this in just in case he ever codes in a datatype with
more than 4 bytes. Then, he only needs to add it to vSizeNames/vSizeLengs.
It might be appropriate to return an error if pData = 0, since this
indicates that the user specified an unknown datatype.
Matt Lewis
2. RE: TK_mem problem and replacement
Matthew Lewis wrote:
>
> > -----Original Message-----
> > From: jordah ferguson [mailto:jorfergie03 at yahoo.com]
>
> > B4, you read this, i have written a tk_mem.e replacement but
> > using pure
> > euphoria code. It is fast and is still undergoing a series of
> > tests. It
> > is safer and faster than the original tk_mem. Soon to be
> > released on RDS
>
> One of the reasons tk_mem was written was to use the memory management
> of
> windows, which has the capability to return RAM to the OS when you're
> done
> with it.
Matt, are you saying EU cannot natively do this? Fill me in as i find my
code working for all examples.
If EU cannot natively do this then we should talk to ROB about this!
>
> > -- What if you are allocating a Byte,Strz or Word? They would still be
> > -- forced to take 4 bytes of memory with below code
>
> You're going to always allocate 4 bytes (even if you only ask for 1).
> Everything is 4-byte aligned.
>
> > If Yes, pData should be a minimum of 4 Bytes. Why bother with
> >
> > if pData != 0 then
> > pData = vSizeLengs[pData]
> > end if
>
> Here, pData is originally an index into vSizeLengs. Derek then makes
> sure
> that you're asking for at least 4 bytes (you might have wanted more). I
> suspect that he's left this in just in case he ever codes in a datatype
> with
> more than 4 bytes. Then, he only needs to add it to
> vSizeNames/vSizeLengs.
> It might be appropriate to return an error if pData = 0, since this
> indicates that the user specified an unknown datatype.
>
> Matt Lewis
>
Matt, i once read a post from Bernie Ryan, when he said that evry time
win32lib crashed, garbage would be left in the OS memory. My TK_mem just
uses EU calls to simulate msets... which incase win32lib crashed EU
would still free the memory. This is for people who have computers with
litter MEM.
jordah ferguson
Sir LoJik
>
>
3. RE: TK_mem problem and replacement
> -----Original Message-----
> From: jordah ferguson [mailto:jorfergie03 at yahoo.com]
> > One of the reasons tk_mem was written was to use the memory
> management
> > of
> > windows, which has the capability to return RAM to the OS
> when you're
> > done
> > with it.
>
> Matt, are you saying EU cannot natively do this? Fill me in
> as i find my
> code working for all examples.
>
> If EU cannot natively do this then we should talk to ROB about this!
This is standard behavior for pretty much all languages, especially C using
malloc/free (which ultimately Euphoria does). You can search the archives
for more detailed discussions on this.
Here's a quote from Rob in December 2000:
"release_mem() appears to call Euphoria's free().
Euphoria's free() calls C's free(), which does not
give the memory back to the operating system.
The memory stays in the heap, ready for use
within the same Euphoria program (either for
calls to allocate(), or for creating new sequences etc.)
C programs on the Amiga or any other system
would likely work the same way. The heap memory
used by C's malloc() and free() is not returned to the
O/S until the application terminates. It's not practical
for any O/S to take back a small piece of memory
from the middle of your address space."
> Matt, i once read a post from Bernie Ryan, when he said that
> evry time
> win32lib crashed, garbage would be left in the OS memory. My
> TK_mem just
> uses EU calls to simulate msets... which incase win32lib crashed EU
> would still free the memory. This is for people who have
> computers with
> litter MEM.
I've never looked into this very closely. I suspect that you could still
have memory leaks if you crash with a machine exception, since Eu isn't
allowed to do its cleanup. Since windows has assigned blocks of memory to
win32lib, it might be able to free those blocks even then, assuming it takes
notice of the fact that your process is no longer running.
The win32lib scheme was directly aimed at computers with less memory,
allowing unused blocks to be put back onto the heap for the OS to parcel out
to other processes that might need them.
Matt Lewis
4. RE: TK_mem problem and replacement
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C21BE3.CDC21510
charset=iso-8859-1
Thanks Matt and Jordah for this discussion.
Matt is essentially correct on this one.
a) There will be provision for larger data types in the future.
b) The minium allocation is always 4 bytes, even if you ask for less. This
is mainly for performance reasons.
c) I should return zero if an unknown datatype is used.
d) Bernie is wrong about RAM acquired by win32lib being locked up if a
win32lib app crashes. It is true that RAM acquired some other way might
still be held if the app crashes, but that's not due to any action in
win32lib. AFAIK, all RAM acquired by win32lib is released by Windows if the
app crashes.
e) Win2lib takes memory from Windows in 16,000 byte chunks (heaps). It doles
out RAM from these heaps. If there is not enough RAM in the current heaps,
it gets enough new heaps to make up what is asked for. When release_mem()
frees up an allocation and if that freeing up, also frees up any heaps,
these heaps are returned to Windows for reuse in this or other apps that
might be running.
Hope this helps.
-----------------
Derek.
> -----Original Message-----
> From: jordah ferguson [mailto:jorfergie03 at yahoo.com]
> Sent: Tuesday, 25 June 2002 2:57
> To: EUforum
> Subject: TK_mem problem and replacement
>
>
>
> Hi Derek,
>
>
> B4, you read this, i have written a tk_mem.e replacement but
> using pure
> euphoria code. It is fast and is still undergoing a series of
> tests. It
> is safer and faster than the original tk_mem. Soon to be
> released on RDS
>
>
> I was Checking tk_mem.e code and found out something rather
> unusual in
> acquire_mem,
> here check out this code.
>
> constant vSizeNames = {Byte, Word, Long, Lpsz, Hndl, HndlAddr, Strz}
> constant vSizeLengs = { 1, 2, 4, 4, 4, 4, 1}
>
> --** START: FROM ACQUIRE_MEM()
>
> -- Check for special datatype "names"
> if pData < 0 then
> pData = find(pData, vSizeNames)
> if pData != 0 then
> pData = vSizeLengs[pData]
> end if
> end if
> --### Problem!!! Below
> -- What if you are allocating a Byte,Strz or Word? They would still be
> -- forced to take 4 bytes of memory with below code
>
> if pData < 4 then
> pData = 4
> end if
>
> --** END: FROM ACQUIRE_MEM()
>
> If Yes, pData should be a minimum of 4 Bytes. Why bother with
>
> if pData != 0 then
> pData = vSizeLengs[pData]
> end if
>
> Derek, PLease check on this and i hope, It doesn't cause any problems.
>
> Cheers,
> Jordah Ferguson
> aka Sir LoJiK
>
>
>
>
==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
==================================================================
------_=_NextPart_000_01C21BE3.CDC21510
Content-Type: application/ms-tnef
5. RE: TK_mem problem and replacement
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C21BE5.8BB8CCC0
charset=iso-8859-1
Actually, now that I look again, I can see a bug in tk_mem. It treats Long,
DWord, Ptr and UInt as the same. This is wrong because Long and DWord are a
signed 32-bit and Ptr and UInt are unsigned 32-bit. I'll fix this
immediately.
---------------
Derek.
==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
==================================================================
------_=_NextPart_000_01C21BE5.8BB8CCC0
Content-Type: application/ms-tnef
