🚀 go-pugleaf

In article <447jvu$1vr@orion.cybercom.net> jerry@cybercom.net (Jerry Shekhel) writes:
>These are good points.  I totally agree that an application using handles
>instead of pointers must be designed a certain way.

I'd point it slightly other way. I'd say "handles prevent me from using 
some convenient programming techniques".

>Why do you keep bringing up VM when it does nothing to solve the problem
>handles are intended to solve?  As for your comments regarding memory
>requirements, I'd like to see some numbers -- code size, peak data size,
>etc.

See below what VM solves and what handles are intended (good word indeed!)
to solve. Essentially, this is a same problem.

What about examples: all my code is for "linear address" system;
only program that was ported to handle-based Win16 API was single
SMTP/PO3 mail client applet (actually, it was turned to Oracle Forms 
"user exit").

Source code has grown approximately by 15-20%; critical regions dealing
with buffer allocation got that "2-3 times" increase I spoke about.
Well, I ready to admit that 2-3 time overall increase was an exaggregation.
I was too frustrated in process of reworking my code to count exact value :(.
Peak data size in my applet is rather small: it is basically summary 
size of all parsed headers + size of current letter body.

I cannot precisely compare binary code size because:

1. Object files contain debugging info and relocation information,
so comparing their size is pointless.

2. Linked user exit DLL contains Oracle runtime code, which is fairly big.

3. 16-bit intel code is bigger than 32-bit one by approx 10% or more,
due to segment loading instruction and better optimisation in 32-bit mode.

BTW, this is another argument against handles: calling lock/unlock routines 
prevents compiler from some register allocations, because calls destroy some
registers. Good register optimisation might drastically increase speed
and decrease code size; I've seen 4 times speed increase when compiled 
with -ot option. When you are concerned about speed, it is reasonable
to avoid extra calls in your code, and use only intrinsic and/or inline
functions. With handles you cannot do it.

4. Browsing linker .MAP files and summarising sizes of appropriate modules 
would take much longer than typing this excuse :). I do not have .MAP file
for DLL on hands, so I would need to compile them.

Anyway, user exit DLL is several times bigger than OS/2 .exe, but (2) and (3)
make this comparison invalid.

>: Actually, there are situation when there _is_ need to do indirection per
>: each access. And when you try to block your accesses, you might create ugly
>: bugs that are very hard to find. On other hand, in VM systems MMU hardware 
> : does indirection for you automagicaly.

>VM has nothing to do with it.  Handles are meant to solve the problem of
>internal fragmentation, while paged VM solved external fragmentation.

Fragmentation is function of number of memory allocations/deallocations.
In fact, it is somewhere near O(n^2) from that number, so internal 
fragmentation is many times smaller than system-wide ("external") one.
VM does three things wrt fragmentation:

1. It eliminates system-wide ("external", as you say) fragmentation.

2. It separates heaps of individual apps, so each app has to deal
only with its individual fragmentation which is much smaller.

3. It provides programs with bigger memory pool, so fragmentation
problem is moved to the future. Many apps would finish faster than
meet fragmentation problem :).

From practical standpoint, VM eliminates fragmentation problem for
wast majority of cases, thus making handles irrelevant for these cases.

>There are handle-based allocation libraries for UNIX. 

I wasn't aware of them, probably because I never needed it.
I always knew it is possible, though.

>MacOS and 16-bit
>Windows have VM but still use handles, and for a reason.  You may agree
>or disagree with the reason, but VM solves a totally different problem.

Well, in Unix and other VM systems I might use any _local_ memory allocation
scheme I would like to have. If fragmentation is an issue for this app,
I might use handle-based package or something else; if it isn't
(which is the case in 99.9999% of cases), I might cope with usual malloc
and single indirection. On other hand, Mac and Win16 force me to use 
handle-based allocation _always_, even when it is just annoyance.

And do not tell me Win16 is efficient wrt memory usage :).

Cheers,
	Fat Brother.

Fatal Error: Couldn't enter Windows, use Doors.