Quantcast

The future of XPCOM memory management

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The future of XPCOM memory management

Jason Orendorff
AddRef and Release constitute a contract between every XPCOM object
and all its users.  The contract governs object lifetimes,
finalization order, and memory management.

Advantages of this specific contract:

  1. It's relatively simple.
  2. It requires no global coordination.
  3. Prompt destruction.  If there are no cycles, objects are
     destroyed as soon as they're no longer needed.
  4. It destroys objects in the right order.

Disadvantages:

  1. It requires manual bookkeeping throughout the codebase
     (nsCOMPtr, NS_ADDREF, NS_RELEASE, already_AddRefed,
     kungFuDeathGrip, etc.)  This clutters up the code, and all the
     virtual method calls and AtomicIncrements can't be good.
  2. The problem of reference cycles is built in.
  3. Interacting with other memory management schemes is painful
     and slow.  (See cycle collector, XPConnect.)

In Mozilla 2, we should change this to require less effort from the
programmer and less clutter throughout the code.  This means coming
up with a new contract that cooperates with garbage collection,
rather than fighting it.

More on this in a few hours.

-j

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Jason Orendorff
On Aug 28, 9:34 am, Jason Orendorff <[hidden email]> wrote:
> More on this in a few hours.

I don't think there's such a thing as a contract that (a) is simple,
(b) is
efficient, (c) supports GC, (d) supports refcounting for objects that
want it,
and (e) really hides memory management implementation details.  So
there will
be design tradeoffs here.

For the sake of having a concrete proposal to chew on, I propose the
following:

  * Drop AddRef and Release from nsISupports.

  * Require all XPCOM objects to be MMgc GCObjects or
GCFinalizedObjects,
    allocated from the same GC allocator as all JavaScript objects.

    Read more about MMgc here:
      http://developer.mozilla.org/en/docs/MMgc

  * Change any code that depends on objects being destroyed in a
specific
    order, or at a specific time, to use some explicit means of
ensuring that
    it really happens that way, rather than depending on reference
counting.

  * Use static tools to replace our uses of nsCOMPtr and friends with
the MMgc
    equivalents, and replace nsISupportsWeakReference with MMgc
GCWeakRefs.

  * Add thread-safety to MMgc using the Spidermonkey request model.

  * Delete the cycle collector.

How did I do?  This proposal nails goal (c), does quite well on (a)
and OK on (b),
and ignores goals (d) and (e).  Maybe you can do better.

I'll be working on the following bug quite soon, so now is the time to
speak up.

  Bug 393034 - Allocate DOM objects using MMgc
  https://bugzilla.mozilla.org/show_bug.cgi?id=393034

-j

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Jonas Sicking-2
In reply to this post by Jason Orendorff
I definitely think we should try to get rid of reference counting in
favor of garbage collection. There are a few things that I'm worried
about and that needs investigation.

How complicated is embedding going to be? I suspect it's going to be
more complicated than now in some ways, since interacting with a GC
engine is probably trickier than simply calling AddRef. At the same
time, environments that use GC, such as java, should have an easier time
avoiding leaks.

How is performance going to be during GC? While we're not writing a
real-time app, we don't want the UI to lock up for seconds while GC is
running. If we get better at detecting inactivity from the user, we
might get away with more here since we can run GC while the user is busy
simply looking at a webpage.

Related to the above, should we attempt to use incremental GC. From what
I understand this should be entierly possible with MMgc. However it
requires that all pointers use special smart-pointers. Including
pointers that are currently raw-pointers. This seems a little bit scary
and easy to forget, but might be very nice for performance.

/ Jonas

Jason Orendorff wrote:

> AddRef and Release constitute a contract between every XPCOM object
> and all its users.  The contract governs object lifetimes,
> finalization order, and memory management.
>
> Advantages of this specific contract:
>
>   1. It's relatively simple.
>   2. It requires no global coordination.
>   3. Prompt destruction.  If there are no cycles, objects are
>      destroyed as soon as they're no longer needed.
>   4. It destroys objects in the right order.
>
> Disadvantages:
>
>   1. It requires manual bookkeeping throughout the codebase
>      (nsCOMPtr, NS_ADDREF, NS_RELEASE, already_AddRefed,
>      kungFuDeathGrip, etc.)  This clutters up the code, and all the
>      virtual method calls and AtomicIncrements can't be good.
>   2. The problem of reference cycles is built in.
>   3. Interacting with other memory management schemes is painful
>      and slow.  (See cycle collector, XPConnect.)
>
> In Mozilla 2, we should change this to require less effort from the
> programmer and less clutter throughout the code.  This means coming
> up with a new contract that cooperates with garbage collection,
> rather than fighting it.
>
> More on this in a few hours.
>
> -j
>

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Jonas Sicking-2
In reply to this post by Jason Orendorff
One thing not raised in your proposal is what to do with objects that
are currently *not* refcounted. Two good examples are strings (nsString
and friends) and arrays, for example nsTArray.

If we turn all currently refcounted objects into GCFinalizedObject, then
any nsString and nsTArray inline members will get their destructor
called when the hosting object is destroyed. Would that be a big
overhead? The devmo docs discourage GCFinalizedObject.

An alternative is to make nsString and nsTArray inherit GCObject, and
make them allocate their internal buffers using GC::Alloc.

However this doesn't fully work for nsTArray since we would still not be
finalizing the objects in the array. We could of course say that you're
not allowed to stick objects that need finalizing in nsTArray, but that
would probably break a good number of current users, for example
PathExpr::mItems in txExpr.h. This contains a number of PathExprItems like:

      class PathExprItem {
      public:
          nsAutoPtr<Expr> expr;
          PathOperator pathOp;
      };

One way to fix this one example would be to make PathExpr::PathExprItem
and Exprs be GCObjects too, and so on. However with this strategy we
would likely be forced to convert a very large number of objects into
GCObject. This certainly sounds doable, but it seems like a lot of work,
much of it risky.

We can't simply make nsTArray a GCFinalizedObject, for two reasons.
First of all we don't really want to pay the overhead of a vtable
pointer. This class is just 4 bytes big when empty, so it would double
in size. Second, nsTArrays often appears as inline members in other
classes. If such classes are GCObjects then the garbage collector will
not be able to detect the inline GCFinalizedObject and finalize it.

/ Jonas

Jason Orendorff wrote:

> On Aug 28, 9:34 am, Jason Orendorff <[hidden email]> wrote:
>> More on this in a few hours.
>
> I don't think there's such a thing as a contract that (a) is simple,
> (b) is
> efficient, (c) supports GC, (d) supports refcounting for objects that
> want it,
> and (e) really hides memory management implementation details.  So
> there will
> be design tradeoffs here.
>
> For the sake of having a concrete proposal to chew on, I propose the
> following:
>
>   * Drop AddRef and Release from nsISupports.
>
>   * Require all XPCOM objects to be MMgc GCObjects or
> GCFinalizedObjects,
>     allocated from the same GC allocator as all JavaScript objects.
>
>     Read more about MMgc here:
>       http://developer.mozilla.org/en/docs/MMgc
>
>   * Change any code that depends on objects being destroyed in a
> specific
>     order, or at a specific time, to use some explicit means of
> ensuring that
>     it really happens that way, rather than depending on reference
> counting.
>
>   * Use static tools to replace our uses of nsCOMPtr and friends with
> the MMgc
>     equivalents, and replace nsISupportsWeakReference with MMgc
> GCWeakRefs.
>
>   * Add thread-safety to MMgc using the Spidermonkey request model.
>
>   * Delete the cycle collector.
>
> How did I do?  This proposal nails goal (c), does quite well on (a)
> and OK on (b),
> and ignores goals (d) and (e).  Maybe you can do better.
>
> I'll be working on the following bug quite soon, so now is the time to
> speak up.
>
>   Bug 393034 - Allocate DOM objects using MMgc
>   https://bugzilla.mozilla.org/show_bug.cgi?id=393034
>
> -j
>

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

L. David Baron
In reply to this post by Jason Orendorff
Jason Orendorff wrote:
>   * Add thread-safety to MMgc using the Spidermonkey request model.

We currently don't pay the cost of thread-safety for most XPCOM objects,
since most objects are main-thread-only.  Would doing this impose
significant performance penalties for locking or atomic operations?  Or
would most operations still be cheap?

>   * Delete the cycle collector.

Are we dropping the multi-language aspects of the platform (introduced
in this milestone, at considerable effort in
https://bugzilla.mozilla.org/show_bug.cgi?id=255942 )?  Or is there a
good way for python to use MMgc as well?

(That said, the python stuff hasn't caught up with the cycle collector,
and would probably leak a lot if it were used as intensively as we use
JS, so I'm not sure how seriously we should take it.)

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Mark Hammond-3
On Aug 29, 9:46 am, "L. David Baron" <[hidden email]> wrote:
> Jason Orendorff wrote:

> >   * Delete the cycle collector.
>
> Are we dropping the multi-language aspects of the platform (introduced
> in this milestone, at considerable effort inhttps://bugzilla.mozilla.org/show_bug.cgi?id=255942)?  Or is there a
> good way for python to use MMgc as well?
>
> (That said, the python stuff hasn't caught up with the cycle collector,
> and would probably leak a lot if it were used as intensively as we use
> JS, so I'm not sure how seriously we should take it.)

Yes, this will be a challenge.  I can't picture how dropping refcounts
would work in the general case with Python.  The XPCOM objects exposed
by Python can be made a GCObject - but I'm not sure how we would
integrate the rest of the Python universe - eg, assuming we have an
arbitrary number of Python objects holding pointers to xpcom objects,
I'm not sure how we would tell the GC about all such references - and
without that knowledge, the GC would cleanup objects that are
referenced.  Deep hacks specific to Python and MMgc might be possible,
but that still screws Perl, etc.

Building a new version of Python that uses MMgc might be possible but
(a) it might not be and (b) every Python extension module would also
need to either (likely) change or (if we are extremely lucky) be
rebuilt.

To summarize, I see that having an external language integrate with
such MMgc is no more - and no less - difficult than integrating with
the existing spidermonkey GC - and I'm not aware of anyone who
believes that is feasible in either the general case, or even just the
specific cases on the table (ie, existing languages with xpcom
bindings)

On the other side of the coin though, the future may be closer to
something like .NET, where languages like Python are reimplemented on
top of a new VM - in which case the GC comes "for free" - but in such
a world xpcom doesn't make as much sense anyway - the VM itself can
make cross-language calls.  So maybe we are asking the wrong question
- what is the future of XPCOM itself, not just its memory management?

Cheers,

Mark

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
In reply to this post by Jason Orendorff
Replying to several messages/thoughts at once:

1. Losing the cycle collector's support for other languages is
necessary to get C++ and JS on a better footing -- a shared GC heap.
But the idea and even code could be harvested for use by other
language runtimes, since we will still face uncollectable cycle
hazards interfacing Java, Python, etc. to C++ and JS.

2. Other languages in Mozilla 2 should prefer to integrate at the VM
level, on Tamarin. See IronMonkey.

3. Jonas's first point: We should avoid making non-refcounted XPCOM
classes be GC-objects without good evidence doing so wins in time and
space overhead. But (separate topic/thread) we hope to use std::string
and the like more where possible, and use Taras's elsa-based tools to
write the mega-patches for us.

4. Jonas's second point: MMgc needs to become more conservative about
interior objects. Currently it does not back up from a pointer to an
interior (via MI or explicit member embedding) to the outermost
(allocation) object.

5. David's first point: the request model is already followed (file
bugs if you can) in Mozilla code (this was not always so). We aim to
keep it, but it does not mean there is any thread-safety cost imposed
on GC'ed objects. Only that the embedding must begin, end, suspend,
resume, and yield requests appropriately (could use some static
analysis help here too). The JS objects that SpiderMonkey creates
already use the request model to do optimistic lock-free
synchronization, so no change there. And we are not imposing such
synchronization on other objects for Mozilla 2, as far as I can see.

/be

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
In reply to this post by Mark Hammond-3
On Aug 28, 6:07 pm, mhammond <[hidden email]> wrote:
> The XPCOM objects exposed
> by Python can be made a GCObject - but I'm not sure how we would
> integrate the rest of the Python universe - eg, assuming we have an
> arbitrary number of Python objects holding pointers to xpcom objects,

MMgc is conservative. So long as Python allocates memory to be scanned
for pointers to MMgc allocations using MMgc's malloc wrapper, MMgc
will find these pointers. You need an MMgc GCRoot subclass (one or
more, perhaps at most one per other language implementation) to root
all the Python objects that are not (or not guaranteed to be) pointed
at by pointers in memory MMgc scans.

> I'm not sure how we would tell the GC about all such references - and
> without that knowledge, the GC would cleanup objects that are
> referenced.

That would be bad, so let's not ;-).

> Deep hacks specific to Python and MMgc might be possible,
> but that still screws Perl, etc.

Perl is not helped much by PyXPCOM, right? How does this differ with
XPCOM-on-MMgc?

> Building a new version of Python that uses MMgc might be possible but
> (a) it might not be and (b) every Python extension module would also
> need to either (likely) change or (if we are extremely lucky) be
> rebuilt.

This is not the way, agreed.

> To summarize, I see that having an external language integrate with
> such MMgc is no more - and no less - difficult than integrating with
> the existing spidermonkey GC -

It's easier because MMgc is conservative -- but I should add that it's
harder if MMgc is used in incremental mode, because you need to impose
a write barrier on Python.

> and I'm not aware of anyone who
> believes that is feasible in either the general case, or even just the
> specific cases on the table (ie, existing languages with xpcom
> bindings)

GC-to-GC cycle collection is easier than refcount cycle collection.
See http://www.cs.cmu.edu/~roc/HetGC.html (I hope this is sound -- I
never did proofs ;-) and Parley from IBM research, where the best link
I can find is:

http://researchweb.watson.ibm.com/vee04/video.html#grove

> On the other side of the coin though, the future may be closer to
> something like .NET, where languages like Python are reimplemented on
> top of a new VM - in which case the GC comes "for free" - but in such
> a world xpcom doesn't make as much sense anyway - the VM itself can
> make cross-language calls.

Precisely -- wherefore IronMonkey.

> So maybe we are asking the wrong question
> - what is the future of XPCOM itself, not just its memory management?

And indeed Jason posted a separate thread on that topic. See you
there :-).

/be

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
On Aug 28, 6:23 pm, "[hidden email]" <[hidden email]> wrote:

> On Aug 28, 6:07 pm, mhammond <[hidden email]> wrote:
>
> > The XPCOM objects exposed
> > by Python can be made a GCObject - but I'm not sure how we would
> > integrate the rest of the Python universe - eg, assuming we have an
> > arbitrary number of Python objects holding pointers to xpcom objects,
>
> MMgc is conservative. So long as Python allocates memory to be scanned
> for pointers to MMgc allocations using MMgc's malloc wrapper, MMgc
> will find these pointers.

I should have written "using an appropriate malloc wrapper". Ideally
only memory that might contain pointers to XPGC (heh) objects would be
allocated with the kContainsPointer MMgc flag.

that may be hard to hook into C-Python. Is it?

/be

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Benjamin Smedberg
In reply to this post by Mark Hammond-3
mhammond wrote:

> Yes, this will be a challenge.  I can't picture how dropping refcounts
> would work in the general case with Python.  The XPCOM objects exposed
> by Python can be made a GCObject - but I'm not sure how we would
> integrate the rest of the Python universe - eg, assuming we have an
> arbitrary number of Python objects holding pointers to xpcom objects,
> I'm not sure how we would tell the GC about all such references - and

Can't you just root them while python holds the external references?

--BDS

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Benjamin Smedberg
In reply to this post by Jonas Sicking-2
Jonas Sicking wrote:

> How complicated is embedding going to be? I suspect it's going to be
> more complicated than now in some ways, since interacting with a GC
> engine is probably trickier than simply calling AddRef. At the same
> time, environments that use GC, such as java, should have an easier time
> avoiding leaks.

I believe that embedders should never see any of this: embedders should not
use XPCOM any more, we should expose real platform-native embedding layers
with a stable API.

--BDS
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Benjamin Smedberg
In reply to this post by Jason Orendorff
Jason Orendorff wrote:


>   * Use static tools to replace our uses of nsCOMPtr and friends with
> the MMgc
>     equivalents, and replace nsISupportsWeakReference with MMgc
> GCWeakRefs.

There are two different uses of weakrefs in our tree:

1) Weak refs used to avoid cycles: A holds a strong-ref to B, which holds a
weak ref to A. This is more COM-safe than holding a raw pointer to A. This
pattern should simply be replaced by object pointers, which I think means
DWB(MyObject*)

>   * Add thread-safety to MMgc using the Spidermonkey request model.

This is the part that has me extremely worried. We would have to propagate
the request model throughout all of our XPCOM code, which is a very tricky
task. As I understand it, the invariants for requests are:

1) GC references may change only within a request
2) blocking (or long-running) activity should not take place within a request

I think that keeping track of whether we're currently in a request would be
 a major headache.

Brendan may kill me for this, but I think that we can and should assert
single-threaded behavior for all of JS and "XPCOM/MMGC": that is, MMGC
should only be on the main thread.

There are necko classes which will want to be accessible via MMGC/XPCOM and
also be internally threadsafe, but I believe that they can root themself on
the main thread and perform all of their multi-thread networking using an
internal threadsafe reference-counting and proxying scheme that is "not XPCOM".

> I'll be working on the following bug quite soon, so now is the time to
> speak up.
>
>   Bug 393034 - Allocate DOM objects using MMgc
>   https://bugzilla.mozilla.org/show_bug.cgi?id=393034

Are we sure that we want to get into the "revamp XPCOM" game just to get
going with fast-path DOM? The approach you mention in comment 14 approach C
makes a lot of sense, without rewriting all of XPCOM:

1) use MMGC for internal DOM references
2) keep using XPCOM for "external" references - XPCOM refs mean the object
is rooted
3) teach XPConnect to use MMGC references for DOM objects

--BDS
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
In reply to this post by Benjamin Smedberg
Benjamin Smedberg wrote:

> mhammond wrote:
>
>> Yes, this will be a challenge.  I can't picture how dropping refcounts
>> would work in the general case with Python.  The XPCOM objects exposed
>> by Python can be made a GCObject - but I'm not sure how we would
>> integrate the rest of the Python universe - eg, assuming we have an
>> arbitrary number of Python objects holding pointers to xpcom objects,
>> I'm not sure how we would tell the GC about all such references - and
>
> Can't you just root them while python holds the external references?

You can root at some cost. But roots aren't cheap, and IIRC Mark used
delegated Python incref/decref to call XPCOM AddRef/Release directly --
cheaper and in sync with Python's ref-counting with background GC memory
management. And with roots, you can still have cycles between heaps (but
these were not addressed by PyXPCOM, and as dbaron noted, the XPCOM
cycle collector's stubs for PyXPCOM need to be fleshed out and tested).

Roots are not the answer for interior nodes. With SpiderMOnkey,
delegated trace (formerly mark) and finalize class hooks help. But any
two memory managers colliding, you want cheaper-than-global-root edge
tracing, and for leak-proofing you must have to do something further to
deal with cycles.

Life is better with a single GC, which is why we are unifying C++ and JS
on top of MMgc for Mozilla 2, and why we are supporting IronMonkey to
add other languages on top of a common memory manager and JITting VM
(along with memory safety and other benefits as motivation, in addition
to avoiding multi-heap integration and cycle-breaking hassles).

/be
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Jason Orendorff
In reply to this post by Benjamin Smedberg
On Aug 29, 11:22 am, Benjamin Smedberg <[hidden email]> wrote:

> Jason Orendorff wrote:
> >   * Add thread-safety to MMgc using the Spidermonkey request model.
>
> This is the part that has me extremely worried. We would have to propagate
> the request model throughout all of our XPCOM code, which is a very tricky
> task. As I understand it, the invariants for requests are:
>
> 1) GC references may change only within a request
> 2) blocking (or long-running) activity should not take place within a request
>
> I think that keeping track of whether we're currently in a request would be
> a major headache.

I am not too worried.  I think I see how this is going to work.

All threads will be in a request all the time, except when doing
blocking I/O or CPU-bound, non-GC-touching stuff.  You'll have to
suspend the request before doing that kind of thing, and resume it
afterwards.  I imagine we'll have a C++ object that knows how to do
this.  (Like nsAutoLock. "nsAutoSuspendRequest", maybe.)

Finding those places would be the only hard part. But if you miss one,
it should be *real* easy to spot and debug. Firefox will seem to hang.
You'll attach a debugger, and all threads will be sitting in
MMgc::waitForGC except for one, which will be blocked on DNS or
compositing video buffers.

> Are we sure that we want to get into the "revamp XPCOM" game just to get
> going with fast-path DOM? The approach you mention in comment 14 approach C
> makes a lot of sense, without rewriting all of XPCOM:
> [...]

Well, my short-term plans are still incremental.  But this
conversation has been dormant since December.  I really want to know
the long-term plan, for both short-term and long-term reasons.

-j

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
In reply to this post by Benjamin Smedberg
Benjamin Smedberg wrote:

> Jonas Sicking wrote:
>
>> How complicated is embedding going to be? I suspect it's going to be
>> more complicated than now in some ways, since interacting with a GC
>> engine is probably trickier than simply calling AddRef. At the same
>> time, environments that use GC, such as java, should have an easier time
>> avoiding leaks.
>
> I believe that embedders should never see any of this: embedders should not
> use XPCOM any more, we should expose real platform-native embedding layers
> with a stable API.

Or an unstable API. It's what everyone else does. Stability arises
through a "conversation" between producers and consumers, and over time
increases, until there's a "big shift". This came up in face-to-face
meetings, and we should hash it out.

New thread in .embedding, cross-posted here with followup-to: set?

/be
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
In reply to this post by Jonas Sicking-2
Jonas Sicking wrote:
> Related to the above, should we attempt to use incremental GC. From what
> I understand this should be entierly possible with MMgc. However it
> requires that all pointers use special smart-pointers. Including
> pointers that are currently raw-pointers. This seems a little bit scary
> and easy to forget, but might be very nice for performance.

Raw pointers should be banned in incremental GC settings. We can use
static analysis to enforce this.

And anyway, we really do need to understand ownership at every edge in
the graph. Right now, a raw pointer is a giant question mark that should
raise alarms about either manual-over-refcounted leak bugs, or else
manually-dropped-early or just plain-old-raw-weak-pointer and therefore
dangling-pointer, exploitable bugs.

/be
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Jason Orendorff
In reply to this post by Benjamin Smedberg
On Aug 29, 8:11 am, Benjamin Smedberg <[hidden email]> wrote:
> mhammond wrote:
> > Yes, this will be a challenge.  I can't picture how dropping refcounts
> > would work in the general case with Python.  The XPCOM objects exposed
> > by Python can be made a GCObject - but I'm not sure how we would
> > integrate the rest of the Python universe - eg, assuming we have an
> > arbitrary number of Python objects holding pointers to xpcom objects,
> > I'm not sure how we would tell the GC about all such references - and
>
> Can't you just root them while python holds the external references?

Yes, but you'd leak any garbage cycles that include both Python and
XPCOM objects--they would be rooted.  That can be fixed, too, with
enough effort.  It's not simple.

-j

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Benjamin Smedberg
In reply to this post by Brendan Eich-2
Brendan Eich wrote:

> Or an unstable API. It's what everyone else does. Stability arises
> through a "conversation" between producers and consumers, and over time
> increases, until there's a "big shift". This came up in face-to-face
> meetings, and we should hash it out.
>
> New thread in .embedding, cross-posted here with followup-to: set?

Sure. The important point was not the stability or instability of the
embedding API, but that it is entirely decoupled from "XPCOMGC".

--BDS
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
In reply to this post by Benjamin Smedberg
Benjamin Smedberg wrote:
> Brendan may kill me for this, but I think that we can and should assert
> single-threaded behavior for all of JS and "XPCOM/MMGC": that is, MMGC
> should only be on the main thread.

Jason addressed the request model fear. Main thread code can't block
indefinitely for i/o already, so the only request suspend points that I
can see right now are

* lengthy, non-GC-graph-mutating computations;
* file i/o that's "blocking, but fast", yet not fast enough for us to
wish to stay in a request;
* required deadlock-with-the-GC avoidance not handled by the request
model itself.

> There are necko classes which will want to be accessible via MMGC/XPCOM and
> also be internally threadsafe, but I believe that they can root themself on
> the main thread and perform all of their multi-thread networking using an
> internal threadsafe reference-counting and proxying scheme that is "not XPCOM".

More than Necko classes are at stake. We know of AllPeers and Songbird
MT XPCOM usage, and I believe Joost too uses XPCOM with shared memory
threads. I do not propose to make all such consumers of XPCOM rewrite
their code for Mozilla 2, even though it could turn out that everyone
agrees on doing that, for good wins in reasonable timeframe.

Proceeding incrementally, removing ref-counting from XPCOM and moving it
to GC, seems a much better approach, since we don't know all the costs
and benefits, and how they trade off for different platform clients.

>> I'll be working on the following bug quite soon, so now is the time to
>> speak up.
>>
>>   Bug 393034 - Allocate DOM objects using MMgc
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=393034
>
> Are we sure that we want to get into the "revamp XPCOM" game just to get
> going with fast-path DOM? The approach you mention in comment 14 approach C
> makes a lot of sense, without rewriting all of XPCOM:
>
> 1) use MMGC for internal DOM references
> 2) keep using XPCOM for "external" references - XPCOM refs mean the object
> is rooted
> 3) teach XPConnect to use MMGC references for DOM objects

This is more work because it bridges two memory managers. It requires
the cycle collector still. We should try to cut to the chase and move
XPCOM to MMgc.

/be
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The future of XPCOM memory management

Brendan Eich-2
In reply to this post by Benjamin Smedberg
Benjamin Smedberg wrote:

> Brendan Eich wrote:
>
>> Or an unstable API. It's what everyone else does. Stability arises
>> through a "conversation" between producers and consumers, and over time
>> increases, until there's a "big shift". This came up in face-to-face
>> meetings, and we should hash it out.
>>
>> New thread in .embedding, cross-posted here with followup-to: set?
>
> Sure. The important point was not the stability or instability of the
> embedding API, but that it is entirely decoupled from "XPCOMGC".

Indeed, and I'm with you on that point. It's non-trivial with exact GC,
since you end up requiring fat handles (roots or scannable thread-local
helpers such as SpiderMonkey's JSTempValueRooters), and these can't be
hidden even with C++ auto-storage-class automation.

Think of the JNI with its global and local (per-activation) roots, and
the need to manage the latter when you create thousands of newborns and
connect each as you go to the live object graph.

We don't want a JNI-like embedding API just to future-proof for exact
GC. We might evolve MMgc toward a more exact mode of operation, but
there's little motivation for that now. So we are probably committing to
at least conservative stack scanning in our GC, by using simple
embedding APIs.

I'm assuming the embedding APIs will involve pointers to GC-allocated
things. Copying strings in and out can get expensive depending on the
embedding. But this is fodder for the new thread.

/be
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
123
Loading...