[Opensim-dev] proposal: cleanup and break up region modules
Cristina Videira Lopes
lopes at ics.uci.edu
Thu Jan 29 13:14:27 UTC 2009
My experience with RESTComms, and having looked at the other modules in
there, is that most of those aren't really "modules" as in "optional
components", but as "the reference implementation of a required
interface that can be replaced with another implementation". For that
reason they can be seen as belonging to core, and be bundled in one
single dll.
Although I would prefer to see each one of them in a separate dll, I
think MW's proposal is perfectly reasonable. It's a good idea to
separate these modules from, at least, OpenSim.Region.Environment.dll,
if not from each other.
MW wrote:
> Putting aside the optimisations for now, as I think that is a
> different question. As if we are going to have a dynamic module system
> then those issues come with it.
>
> While I think having every module in a separate dll/project is too
> much. As Stefan said I think we have just about enough projects in the
> core as it is. But I can see a case for moving all the modules that
> are currently in OpenSim.Region.Environment, into a single separate
> project/dll called something like OpenSim.Region.CoreModules.
>
> And if we could as Justin said, impove the module loading system, so
> that the operator can turn on and off the loading/usage of any modules
> in a single dll.
>
> */Stefan Andersson <stefan at tribalmedia.se>/* wrote:
>
> I think that some confusion stems from the fact that it's a
> difference between referencing the assembly, and dynamically
> instancing classes out of it.
>
> If you reference classes directly, as in
>
> mything = new Thing();
>
> where thing could be a module, albeit _referenced_, not _loaded_
>
> is a huge difference to
>
> mything = loadedAssembly.Instantiate( "Thing" );
>
> in the former, the jit compiler can do all kinds of neat
> optimizations when referencing classes in the Assembly, since it
> has both the referenced component and the referrer at hand. It can
> also inline and optimize away type validity checks and trusted
> domain checks.
>
> In the latter, it really can't, and need to wrap everything in
> prudent encapsulation, protection and indirection.
>
> Optimization points aside, I would hate for us to expand the core
> modules into separate projects just because we can; I think we
> would have to add 20 more projects to the solution and that would
> just suck - especially now that we have cleaned out so many. Some
> of the these new projects will have just a handful of classes,
> which is just an absurd waste of resources for something that
> should be used in 95% of the setups.
>
> I actually don't know how mono addins work, but in the .net
> framework individual classes are referenced by assembly and class
> if loaded at runtime, so for examble
>
> authModule= "MyAuthLib.dll, MyAuthenticator" would reference the
> class MyAuthenticator in the dll MyAuthLib.dll - which means that
> you can lump as many of those together in an dll that you want to.
>
> so we should make sure we can do something liket that, and instead
> try to lump modules that share a common domain together.
>
> The only two reasons to ever split an assembly into two is from
> * references being too different (if you want to re-use them
> separately)
> * encapsulation and security issues (actuallly USING internal as
> it was intended)
>
> So, what I'm saying is that we should strive towards a situation
> where the core modules are bundled into a minimal set of
> assemblies, and the rest put on forge.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
> > Date: Thu, 29 Jan 2009 11:28:19 +0100
> > From: DrScofield at xyzzyxyzzy.net
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] proposal: cleanup and break up region
> modules
> >
> > Tleiades Lauridsen wrote:
> > >
> > >
> > >> Date: Thu, 29 Jan 2009 08:31:48 +0100
> > >> From: DrScofield at xyzzyxyzzy.net
> > >> To: opensim-dev at lists.berlios.de
> > >> Subject: Re: [Opensim-dev] proposal: cleanup and break up
> region modules
> > >>
> > >> Tleiades wrote:
> > >> >> I'd be much more of a fan of having each module a seperate
> dll. Files
> > >> >> are cheap too. :) And that makes it very clear to people
> what they are
> > >> >> loading, and what they aren't loading.
> > >> >>
> > >> >
> > >> > (On the fear of talking about performance prematurely)
> > >> > Won't that cause problems for the JIT'er?
> > >> >
> > >> > Normally access to member variables gets optimized away
> into a direct
> > >> > memory access rather than invocation of a JSR. If I recall
> correctly
> > >> > this optimization does not work for dynamically loaded
> assemblies.
> > >>
> > >> well, if that's the case, then it's not working currently
> either :-)
> > > currently
> > >> we lump all region modules into one large super DLL and load that
> > > dynamically.
> > >
> > > I guess what I'm saying is that dll files are not as cheap as
> it is
> > > being implied. Having an application dynamicallly load a large
> number of
> > > dll's at runtime, is less efficient that loading a few large dll's
> > > during load time. The JIT'ed code will be less efficient and
> loadtime of
> > > the application will increase. While load time may not be a
> big issue, I
> > > believe it is best to give the JIT engine the best working
> condition.
> >
> > we are always loading at runtime --- or let me ask the other way
> round: what do
> > you define as "loadtime"?
> >
> >
> > >
> > > As I understand it the JIT engine and assembly loader have
> been designed
> > > based on a use pattern which states: "Most assemblies will be
> loaded
> > > during application load time, and only few assemblies will be
> loaded at
> > > a latter stage",
> >
> > well, we are loading at runtime then.
> >
> > --
> > dr dirk husemann ---- virtual worlds research ---- ibm zurich
> research lab
> > SL: dr scofield ---- drscofield at xyzzyxyzzy.net ----
> http://xyzzyxyzzy.net/
> > RL: hud at zurich.ibm.com - +41 44 724 8573 -
> http://www.zurich.ibm.com/~hud/
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090129/756cc687/attachment-0001.html>
More information about the Opensim-dev
mailing list