Re: New binaries

Thanks, Stephen.  As the person active on this list who has their
fingers most in the code, your explanations are really appreciated!

> The garbage collector involves inverting every oop (pointer to an object)=
 during the mark phase. What is your interest in forking the VM?

An alternative GC could help with that, obviously.  I'm interested in
scaling by forking to thousands of processes, each to handle 1 active
user.  If the private data could get to be on the order of a megabyte,
this could be interesting.

> Understood. At the stage, your only option would be to manually remove
> classes from the image. This would very much be a trial and error
> affair. I couldn't give you a list of the minimum set of classes
> required (though there are some pretty obvious requirements - Object,
> Array, SmallInteger, etc.).

I'm hoping Dave Griswold can give some hints on how to load the
sources to build up an image.  I presume I it's easier to figure out
loading classes than removing them.

> These all sound like production issues though, and Strongtalk is not
> nearly at production quality, yet.

Well, there's production and there's production.  Obviously Socket is
a prerequisite for much interesting work.

../Dave

On Dec 31 2009, 3:32=A0pm, talksmall <[email protected]>
wrote:
> Hi Dave,
>
> On Dec 31, 7:53=A0pm, Dave Mason <[email protected]> wrote:
>
> > Thanks, Stephen.
>
> > > Unless you were interested in a very constrained embedded application=
 I doubt this would be significant enough an overhead to worry about.
>
> > Actually, the memory-footprint/image-size isn't my primary concern,
> > although anything that got moved-around/garbage-collected and hence
> > would bump actual memory usage following a fork() would be an issue.
>
> Well, regardless of whether or not things get moved around, a full
> garbage collection will write to every page in object memory that
> contains part of an object accessible from the roots. The garbage
> collector involves inverting every oop (pointer to an object) during
> the mark phase. What is your interest in forking the VM?
>
>
>
> > The reasons for wanting to be able to minimize the image are 2-fold:
>
> > 1) for reliability/security/audit reasons, I want to be able to review
> > all the code in an image, so the less, the better;
>
> Understood. At the stage, your only option would be to manually remove
> classes from the image. This would very much be a trial and error
> affair. I couldn't give you a list of the minimum set of classes
> required (though there are some pretty obvious requirements - Object,
> Array, SmallInteger, etc.).
>
> These all sound like production issues though, and Strongtalk is not
> nearly at production quality, yet.
>
>
>
> > 2) presumably, the fewer classes, the higher the likelihood that the
> > compiler can find singleton message dispatch and hence in-line code
> > and get better performance. (I haven't looked at the compiler, so this
> > is pure speculation.)
>
> Actually, the JIT compiler only looks at the information contained in
> the inline caches within methods that are populated from actual
> program execution, so it will only inline code from methods that have
> actually been executed as a result of a message send at a particular
> call site. This means that the number of classes in an image will not
> directly influence the effectiveness of code inlining. The compiler
> does not compile all code, only those parts that are executed
> frequently enough to trigger recompilation. Even after running for an
> extended period, most of the code in the image will not be compiled to
> native code, only those bits that have proven to be performance
> critical (by tripping the performance counter).
>
>
>
> > > If you are interested in porting Seaside, one obstacle you will face
> > > is the absence of continuations (either full or partial) in the
> > > Strongtalk VM.
>
> > Actually, Seaside 3.0 can work without continuations, although partial
> > continuations are necessary for certain kinds of operations.
>
> OK. You will still need to implement socket support to get this
> working. I'd start with this as a first step. Let me know if there's
> anything I can do to help with this, and I'll do my best to help out
> as time permits.
>
> Regards, talksmall

--

You received this message because you are subscribed to the Google Groups "=
Strongtalk-general" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to strongtalk-general+unsubscrib=
[email protected].
For more options, visit this group at http://groups.google.com/group/strong=
talk-general?hl=3Den.