hotsphink

This is more of a comment on the MEMORY-MANAGEMENT.md document than it is an issue with the proposal.

I find it difficult to understand the reachability implications of the proposal. The main section of the document (before the "weak map" section) directly addresses this, though I still find it hard to follow. Partly because it attempts to explain things in terms of weak references and strong references, and as far as I can tell nothing in this proposal uses weak references at all. If you are in a context and have access to an AsyncContext.Variable instance, then you can access the value. A weak reference would imply that you might not be able to get the value, if nothing else keeps it alive. (At least, that's the simplest and most common form of weakness.) This confusion is made worse by the "weak map" section, because it starts making recommendations about converting strong references to weak references at some point in time.

I think part of the problem is the unfortunate term "weak map". Weak maps im

hotsphink

Issues / annoyances encountered while adding jj support to Mozilla automation:

➤ had to fall back to git format-patch to get a patch in the right format.

Perhaps this could be done with a bunch of template stuff, or perhaps the upstream receiver could allow a more jj-compatible format.

➤ having to pass --no-graph to every single jj log invocation.

At least -G would be better, even though I usually only use --long-parameters in automation. I could have aliased "info" to ["log", "--no-graph"], but I don't like depending on magic config settings like that. It's harder for readers to see what the automation is doing.

hotsphink

• (non-spec) should immutable ABs always have immobile data? (Are there inline immutable ABs?) I was thinking that if you have an immutable AB or a frozen view of one, that we could freely hand out internal pointers. But with inline or nursery-allocated data, that is still not necessarily safe.

• would an explicit borrow mechanism like https://gist.github.com/domenic/a9343fa787ba54b4ba3a60882c49cc32 cover the use cases here?

  • it's not a great match for ROM views. "I own this view and nothing else is going to write to it" doesn't say what happens when you try to write anyway. Failing or throwing violates the spec. CoW would "fix" it, but would basically be a big lie.

• the Motivation section in the proposal is persuasive (both examples)

• the added methods (transferToImmutable and sliceToImmutable) make things start to feel a little clunky, when added to transferToFixedLength, like there should be a more general transfer/slice mechanism that covers the full set of transformations we might end up with (fi

hotsphink

• (non-spec) should immutable ABs always have immobile data? (Are there inline immutable ABs?) I was thinking that if you have an immutable AB or a frozen view of one, that we could freely hand out internal pointers. But with inline or nursery-allocated data, that is still not necessarily safe.

• would an explicit borrow mechanism like https://gist.github.com/domenic/a9343fa787ba54b4ba3a60882c49cc32 cover the use cases here?

  • it's not a great match for ROM views. "I own this view and nothing else is going to write to it" doesn't say what happens when you try to write anyway. Failing or throwing violates the spec. CoW would "fix" it, but would basically be a big lie.

• the Motivation section in the proposal is persuasive (both examples)

• the added methods (transferToImmutable and sliceToImmutable) make things start to feel a little clunky, when added to transferToFixedLength, like there should be a more general transfer/slice mechanism that covers the full set of transformations we might end up with (fi

hotsphink

• (non-spec) should immutable ABs always have immobile data? (Are there inline immutable ABs?) I was thinking that if you have an immutable AB or a frozen view of one, that we could freely hand out internal pointers. But with inline or nursery-allocated data, that is still not necessarily safe.

• would an explicit borrow mechanism like https://gist.github.com/domenic/a9343fa787ba54b4ba3a60882c49cc32 cover the use cases here?

  • it's not a great match for ROM views. "I own this view and nothing else is going to write to it" doesn't say what happens when you try to write anyway. Failing or throwing violates the spec. CoW would "fix" it, but would basically be a big lie.

• the Motivation section in the proposal is persuasive (both examples)

• the added methods (transferToImmutable and sliceToImmutable) make things start to feel a little clunky, when added to transferToFixedLength, like there should be a more general transfer/slice mechanism that covers the full set of transformations we might end up with (fi

hotsphink

• (non-spec) should immutable ABs always have immobile data? (Are there inline immutable ABs?) I was thinking that if you have an immutable AB or a frozen view of one, that we could freely hand out internal pointers. But with inline or nursery-allocated data, that is still not necessarily safe.

• would an explicit borrow mechanism like https://gist.github.com/domenic/a9343fa787ba54b4ba3a60882c49cc32 cover the use cases here?

  • it's not a great match for ROM views. "I own this view and nothing else is going to write to it" doesn't say what happens when you try to write anyway. Failing or throwing violates the spec. CoW would "fix" it, but would basically be a big lie.

• the Motivation section in the proposal is persuasive (both examples)

• the added methods (transferToImmutable and sliceToImmutable) make things start to feel a little clunky, when added to transferToFixedLength, like there should be a more general transfer/slice mechanism that covers the full set of transformations we might end up with (fi

hotsphink

diff --git a/js/public/HeapAPI.h b/js/public/HeapAPI.h
index 0f0a15119a..77be945f8b 100644
--- a/js/public/HeapAPI.h
+++ b/js/public/HeapAPI.h
@@ -489,6 +489,9 @@
     return asCell();
   }
 
+  bool operator==(const GCCellPtr other) const { return ptr == other.ptr; }
+  bool operator!=(const GCCellPtr other) const { return ptr != other.ptr; }

hotsphink

eval(`function f() { return "♬"; }`);
eval(`function f2() { return "x"; }`);

hotsphink

g = newGlobal({ newCompartment: true });
dbg = new Debugger();
dbg.addDebuggee(g);
dbg.onNewScript = (script) => {
  const src = script.source;
};
g.eval(`function f() { return "♬"; }`);
g.eval(`function f2() { return "x"; }`);

hotsphink

g = newGlobal({ newCompartment: true });
dbg = new Debugger();
dbg.addDebuggee(g);
dbg.onNewScript = (script) => {
  const src = script.source;
  const h = Object.create(null);
  for (const prop of Object.getOwnPropertyNames(src.__proto__)) {
    Math.sin(src);
    try {
      h[prop] = src[prop];