[DotGNU]Re: [Mono-list] Mono / C# on PDAs

[Stephen Compall]

Gopal V wrote:
> If memory serves me right, Stefan Matthias Aust wrote:
> 
>>Even the most current Java VM from Sun has the problem that each 
>>application has its own heap which contains its own copy of the classes, 
>>duplicating everything.  

There is a possible solution for part of this problem (don't tell Sun!), 
derived from GNU Emacs. Here is part of Appendix (elisp)GNU Emacs 
Internals::.

(elisp)Building Emacs::
    Compilation of the C source files in the `src' directory produces an
executable file called `temacs', also called a "bare impure Emacs".  It
contains the Emacs Lisp interpreter and I/O routines, but not the
editing commands.

    The command `temacs -l loadup' uses `temacs' to create the real
runnable Emacs executable.  These arguments direct `temacs' to evaluate
the Lisp files specified in the file `loadup.el'.  These files set up
the normal Emacs editing environment, resulting in an Emacs that is
still impure but no longer bare.

    It takes a substantial time to load the standard Lisp files.
Luckily, you don't have to do this each time you run Emacs; `temacs' can
dump out an executable program called `emacs' that has these files
preloaded.  `emacs' starts more quickly because it does not need to
load the files.  This is the Emacs executable that is normally
installed.

...

(elisp)Pure Storage::
    Emacs Lisp uses two kinds of storage for user-created Lisp objects:
"normal storage" and "pure storage".  Normal storage is where all the
new data created during an Emacs session are kept; see the following
section for information on normal storage.  Pure storage is used for
certain data in the preloaded standard Lisp files--data that should
never change during actual use of Emacs.

    Pure storage is allocated only while `temacs' is loading the
standard preloaded Lisp libraries.  In the file `emacs', it is marked
as read-only (on operating systems that permit this), so that the
memory space can be shared by all the Emacs jobs running on the machine
at once.  Pure storage is not expandable; a fixed amount is allocated
when Emacs is compiled, and if that is not sufficient for the preloaded
libraries, `temacs' crashes.
EOF

So this "marked as read-only", coupled with an "unexec" (what I'm 
guessing the dump is called), could help in this case. Of course, it 
could cause problems with cross-compiling....but if there was just 
enough memory to load a single interpreter up once, then that 
interpreter could then be multi-loaded as much as you wanted.

> Last time someone checked libffi had problems ... at least libffi 
> included with pnet had problems ... But that was in July and now
> it's a good 5 months past now .. So that information might be out
> of date now ..

Rhys told me that he had never heard of ffcall before I mentioned it to 
him in #dotgnu. I gather it's a replacement for libffi. Here's a bit 
from the GNUstep installation HOWTO 
(http://www.gnustep.org/resources/documentation/GNUstep-HOWTO):

`ffcall libraries (HIGHLY RECOMMENDED)'
      This is a library that provides stack frame handling for
      NSInvocation and NSConnection. This library is highly recommended.
      The previous builtin method for stack frame handling is no longer
      supported and may be removed in the future.  ffcall is under GNU
      GPL. As a special exception, if used in GNUstep or in derivate
      works of GNUstep, the included parts of ffcall are under GNU LGPL.

`libffi library (OPTIONAL)'
      This is a library that provides stack frame handling for
      NSInvocation and NSConnection similar to ffcall. However, libffi
      is not as well tested as ffcall so you should not use it unless
      you are familiar with potential problems. Use this instead of
      ffcall. You don't need both.

So here is Bruno Haible's ffcall page (GNU FS directory entry being 
out-of-date): http://www.haible.de/bruno/packages-ffcall-README.html

-- 
Stephen Compall
Also known as S11001001
DotGNU `Contributor' -- http://dotgnu.org

But how you can encourage greater production of works in the 1920's by
extending copyright today escapes me, unless they have a time machine
somewhere.
	-- RMS, "Copyright and Globalization in the Age of Computer
		Networks", on retroactive copyright extension by the
		U.S. Government