Jonathan Chayce Dickinson wrote:
> 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.
Erm, CAN AOT a specific version.
>
> 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
