On Wed, Sep 3, 2008 at 8:05 AM, David Griswold <david.griswold.256 at gmail.com
> wrote:

> After sleeping on it, I woke up and realized that V8 is almost certainly
> not multi-threaded at the client code level (within a single VM instance),
> since they have that indirection... the indirection sounds more like a
> traditional object table, like VisualWorks, and I don't see how they could
> possibly have made something like that multi-threaded since performance
> would critically depend on caching the body pointer within a method
> activation.  But they can't do that because another method might be adding
> or removing properties while the method is running, and that is way too
> fine-grained to be doing any kind of check.
>

Look at include/v8.h which explains the concurrency model which sounds very
similar to Strongtalk:

 * Multiple threads in V8 are allowed, but only one thread at a time
 * is allowed to use V8.  The definition of 'using V8' includes
 * accessing handles or holding onto object pointers obtained from V8
 * handles.  It is up to the user of V8 to ensure (perhaps with
 * locking) that this constraint is not violated.
 *
 * If you wish to start using V8 in a thread you can do this by constructing
 * a v8::Locker object.  After the code using V8 has completed for the
 * current thread you can call the destructor.  This can be combined
 * with C++ scope-based construction as follows:
 *
 * \code
 * ...
 * {
 *   v8::Locker locker;
 *   ...
 *   // Code using V8 goes here.
 *   ...
 * } // Destructor called here
 * \endcode
 *
 * If you wish to stop using V8 in a thread A you can do this by either
 * by destroying the v8::Locker object as above or by constructing a
 * v8::Unlocker object:
 *
 * \code
 * {
 *   v8::Unlocker unlocker;
 *   ...
 *   // Code not using V8 goes here while V8 can run in another thread.
 *   ...
 * } // Destructor called here.
 * \endcode
 *
 * The Unlocker object is intended for use in a long-running callback
 * from V8, where you want to release the V8 lock for other threads to
 * use.
 *
 * The v8::Locker is a recursive lock.  That is, you can lock more than
 * once in a given thread.  This can be useful if you have code that can
 * be called either from code that holds the lock or from code that does
 * not.  The Unlocker is not recursive so you can not have several
 * Unlockers on the stack at once, and you can not use an Unlocker in a
 * thread that is not inside a Locker's scope.
 *
 * An unlocker will unlock several lockers if it has to and reinstate
 * the correct depth of locking on its destruction. eg.:
 *
 * \code
 * // V8 not locked.
 * {
 *   v8::Locker locker;
 *   // V8 locked.
 *   {
 *     v8::Locker another_locker;
 *     // V8 still locked (2 levels).
 *     {
 *       v8::Unlocker unlocker;
 *       // V8 not locked.
 *     }
 *     // V8 locked again (2 levels).
 *   }
 *   // V8 still locked (1 level).
 * }
 * // V8 Now no longer locked.
 * \endcode

and

   * Start preemption.
   *
   * When preemption is started, a timer is fired every n milli seconds
   * that will switch between multiple threads that are in contention
   * for the V8 lock.


>
>
> Having an object-table indirection isn't as bad for performance as it
> sounds because you can cache the body pointer within a method activation,
> which I seem to remember L. Peter Deutsch pointing out a long time ago.
> But if the average method is very small it will have very few
> instvar/property accesses, which reduces the effectiveness of the caching
> (although if there are *no* property accesses you can skip the indirection
> altogether, which helps compensate).   So that is something that can benefit
> tremendously from inlining à la Strongtalk, which merges activations and
> thus increases the possible scope of the cached pointer.  But if they are
> not inlining, the performance sounds like it would be more restricted to a
> sort of VisualWorks kind of range (which of course is not bad, but wouldn't
> threaten Strongtalk).
>
> Plus, the additional word for the indirection is one more word of overhead
> in the header, so I don't see how they could get less than a two word
> header.  I thought Lars told me it was one word, but I don't see how they
> could do that; maybe he wasn't counting the indirection as part of the
> header.
> -Dave
>
> On Tue, Sep 2, 2008 at 11:15 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>
>> > state-of-the-art multi-threaded design
>>
>> Can you say more about this? I can't find any information about V8's
>> thread handling and concurrency options.
>>
>> Cheers,
>>  - Andreas
>>
>> [...]
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080903/7c72a14d/attachment.htm