2008/7/2 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Jul 1, 2008 at 4:12 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> +1 to moving named primitive into image
>>
>> +1 to make use of primitive returning value (this would affect the
>> code generator, but hell, its way better to have a notion why it
>> failed than simply guessing in the dark room,  like any currently
>> primitive failure code does)
>>
>> +1 to eliminating pushRemappableOop:/popRemappableOop . (A question
>> however, how you would handle heap overflows, when evil primitive
>> generates massive object or lots of tiny objects?)
>
> It is much the same as it is now.  A large allocation attempt (e.g. in
> primitiveNewWithArg) either succeed, possibly causing a garbage collection
> very soon after, or fails.  The garbage collector is allowed to run in
> primitiveNewWithArg et al.  But allocations at any other time cannot cause
> the garbage collector to run and are known to fit within the extra memory
> reserved for the interpreter.  These allocations always succeed but may
> exceed some threshold which will cause a garbage collection very soon
> thereafter.
>
> Memory will look something like this:
>     ->  start of heap
>            ... lots of objects ...
>     -> young start
>            ... not so many objects ...
>     -> free start/eden
>            ... small amount of free space (a few hundred k) ...
>     -> scavenge threshold
>            ... free memory (megabytes)...
>     -> VM reserve start
>            .... very few k (e.g. 8k) ...
>     -> fwd block reserve
>     -> end
>
> The allocation pointer is free start/eden.  A new object is allocated here
> and advances free start/eden.  We will dispense with freeBlock and its
> header for speed.
>
> primitiveNewWithArg (et al) can allocate up to VM reserve start.  An attempt
> beyond that can trigger a garbage collection but the retry cannot exceed VM
> reserve start.
>
> Any other allocation can exceed VM reserve start but not fwd block reserve.
>  Exceeding fwd block reserve is an internal fatal error that should not
> happen if VM reserve is large enough.
>
> Any allocation that pushes free start/eden beyond scavenge threshold sets a
> flag that will cause the VM to perform an incrementalGC on the next send or
> backward branch.
>
> The net result is that pointers only move during primitives that do
> substantial allocations (primitiveNewWithArg, anything that allocates lots
> of objects) and only these primitives need to use
> pushRemappableOop:/popRemappableOop.
>
> The details can vary but the essentials are to arrange that for allocations
> in the course of execution (e.g. creating a block,creating the message
> argument of a doesNotUnderstand:, creating a primitive failure value,
> flushing a stack page to heap contexts, etc, etc) the garage collector will
> not run and so the VM does not need to manage pointers in local variables.
>  It can assume these values will not change and remain valid until the next
> send or backward branch.
>
>

Agreed, most of primitives can't pass over 8k hard limit, except those
which excessively deal with i/o (like taking a screenshot).
Good, i found that both socket and file prims using an array argument
passed as buffer, where plugin would store received data.
I know at least single place where it can create a ByteArray of
arbitrary size (but this is introduced in Hydra, and we will get to it
;) ).

In any case, removing pushRemappableOop:/popRemappableOop pattern
would require to overview all places where its used, so at least for
core plugins, which live with regular VM this could be done in single
swift cut'n'throw away manner.


>> (a little OT .. )
>>
>> Another question, is how would you sync there changes with Hydra (if
>> you having plans of course)?
>
> This *must* be done.  I expect we'll spend quite a lot of time communicating
> to make this happen.  I am about to extend the translator for the stack
> interpreter.  But basically its my job to fit Cog into Hydra.
>
> My own OT:
>
> BTW, did you see my comment about renaming Hydra?  I think "String" is a
> much better name. Strings are composed of threads.  Smalltalk comes from
> Alan Kay's distaste for the kinds of names people were using for programming
> languages in the 60's & 70's, names like Zeus and Thor.  Hence Smalltalk.
>  Hydra is another mythic name.  Cog is a small element in a larger whole
> (and a cool advert by Honda).  Anyway, think it over...
>

Naming things is not my best talent. :) A name "Hydra" is not really
my idea (originally it came from Andreas colleague afaik).
I can say that i like it: Hydra has many heads. But if you find it too
pretentious, hmm. A "String" is directly opposite to it.. Its too
plain boring & gray :)
There can be many criteria how to pick a name: ones care that name
should sell itself, others want to put meaning in it (to conform
idea). I personally prefer  names which simply sound good. :)

>
>> I have many changes in CodeGenerator and some in VMMaker , to simplify
>> my day's job :)
>
> Could you email me your current VMMaker package, or a link to it?  And could
> you summarise the changes you've made and why?  I'll do the same.
>

A package available at
http://jabberwocky.croquetproject.org:8889/HydraVM.
Just made snapshot.

Yes, i would write a summary, meanwhile you  can read a summary about
Hydra here:
http://squeakvm.org/~sig/hydravm/devnotes.html

>> In fact, it would be good to make a clean refactoring of it:
>> - make inst vars of Interpreter/ObjectMemory be the interpreter instance
>> state
>> - make class vars be the part of VM global state
>> - make pool vars be the constants
>> - same could be applied to methods (instance/class side)
>>
>> Currently things are little messy, since i made incremental changes to
>> existing model.
>>
>> Another thing, which doesn't makes me sleep well, is that by using
>> thread specific storage, it would be possible to avoid passing
>> interpreter instance to each function/primitive. Too bad, GCC (on
>> windows) support a __thread__ specifier only in latest release , which
>> is 'technology preview' how they calling it :)
>> If we could use this, it would be possible to make Hydra nearly as
>> fast as current Squeak VM.
>> And there is no point to argue do we have right to use thread specific
>> storage or not: consider that Hydra can run on platforms which can
>> support threads. And since we already using threads, why we can't use
>> thread-specific storage.
>
> You need is an abstraction layer, e.g. implemented with macros that
> insulates the Slang code form the platform thread system details.  You then
> implement the abstraction layer as thinly as possible.  I've done this with
> the threaded API extension of the VW FFI.  Its not hard.  You may be able to
> find GPL versions out there.
>
> best
> Eliot
>
>> ... (stopping OT)
>>



-- 
Best regards,
Igor Stasenko AKA sig.