[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen Compall
Subject: Re: [DotGNU]Re: [Mono-list] Mono / C# on PDAs
Date: Tue, 26 Nov 2002 13:09:14 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021121

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


(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.

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 (

`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):

Stephen Compall
Also known as S11001001
DotGNU `Contributor' --

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
        -- RMS, "Copyright and Globalization in the Age of Computer
                Networks", on retroactive copyright extension by the
                U.S. Government

reply via email to

[Prev in Thread] Current Thread [Next in Thread]