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

[Gopal V]

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.  

IIRC, we need to load classes into memory ... but there seems no escape
from this anyway ... The fixups needed after loading make this necessary.
(OTOH, Rhys's other projects uses an MMAP loading model which is *very* 
efficent)

pnet's mscorlib.dll will be about 200k ~= the amount of heap needed ...
(or strip down....)

> You say, it's not yet available for the Zaurus?  

"If" they are not available ..

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

> "internal calls" (whatever that is) means to redo the Qt bindings?  

Not exactly ... it would be relatively easy to make a dump marshaller/
unmarshaller for PInvoke and run InternalCalls (the more flexible model)
to emulate PInvoke behavior ... But that's sort of extreme ..

> perhaps larger that porting libffi. 

it would be much better if there was libffi support ... But there are places
where you *cannot* write libffi calls ... there we can try the fallback
model..

For example I would probably prefer not to use libffi for embedding pnet
in Apache (which is currently possible without libgc, and therefore useless 
for production purposes) ... I'm more likely to hack my own mod_pnet.c which 
will embed Apache API as internal calls ... (faster, flexible ..)

> So, not caring about the politically correctness and/or the pureness of 
> freedom, and assuming, that the same IL code can run with both mono and 
> pnet, it looks like the best way is to start with pnet as this might run 
> right now and then - possibly - switch to mono once there's a 
> native-code-compiling-JIT for the ARM processor.

We have an experimental JIT planned on after  (or was it for) 0.5.0 .. 
Writing an ILCoder to generate native code wouldn't break portability 
either ... 

But well ... if pnet works on a Zaurus it would be nice , please do
test it ... Or if you want to memory stress pnet on a stock PC use the
-H and -S options to control stack & heap allocations.. (our current 
x86 unrollers take a lot of memory...so the CG core would be better 
for this testing)

Gopal
-- 
The difference between insanity and genius is measured by success