Sander van Rossen wrote:
> On Dec 27, 2007 8:39 PM, Johann MacDonagh <[EMAIL PROTECTED]> wrote:
>
>> On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote:
>> What you're saying is that after Assembly 1 was AOTed, and then
>> Assembly 2 was AOTed, it would be impossible to change the class
>> SomeType without having to re-AOT Assembly 2?
>>
> <snip>
>
> Yes, but once you perform all kinds of optimalisations on those
> classes (like inline small functions) then you'd have to recompile..
> And if you don't do these optimalisations... then you might as well JIT
>
I am going to play the fence sitter here. It must be possible to do it
AOT, you just need to statically link all the generic classes, so when
you AOT something that USES a generic class you 'ungeneric' it using the
type parameter and drop it into the AOT binary. And because we still
have the original generic IL assembly you cant AOT a specific version of
that class.
It's a bloody mission though. Not to mention the conversation me and
xfury had, all those .bins lying around are open to attack from viruses.
It's doable, but is it worth it?
In the end it's better to be safe then sorry. Here is an IDEA of what we
could do (which each step having months of separation from the last):
1. Allow for an AOTted binary file alongside a IL binary (e.g. bla.dll,
bla.bin), only allow loading the bin for the time being (e.g.
Path.ChangeExtension(assembly, ".bin")), but leave in stubs for a JITter.
2. AOT the AOT and include it on the SharpOS HDD.
3. Bring the AOT, as is, in and precompile everything when the assembly
is loaded (but still allow the AOTted binaries).
4. Appropriate the AOT and make a JIT (but still allow the AOTted binaries).
5. Write a real JITter that does realtime optimizations and such goodness.
I think Johann is frustrated because he thinks we are going to waste
time on a JITter, and I quite frankly agree. Not all of us have the 1337
skillz to make a JITter (me especially) and would better spend our time
working on other stuff, such as architectural assemblies and having a
kernel that can load up assemblies will help us tremendously. XFury is
doing a fantastic job on the window system and such, put there is a
point in the middle at which we need to meet: so I could, for instance,
start writing the wiring between xfury and darxkies. A rich console
class and whatnot will really help xfury.
Just remember Johann, having .bins lying around everywhere could really
open up some nasty security holes. We need to give ourselves an escape
route, and having an un-implemented JITter that just calls the AOT or
loads binaries could save us huge hassles later on when/if we decide
that a JITter was the route to go.
So my above mentioned method should really keep everyone happy and then
we can change evolve as we get a better perspective of our needs.
--
Jonathan Dickinson
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
