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];

hotsphink

{"base_commit": "2bc2e00709312d553fb80fc9202f51ea8001e59a", "patch_format": "git-format-patch", "patches": ["RnJvbSBhMzAxZmI2OTZhMGY1MmMyOGRkNmFiZmZmOTc0ZTk5ODgzZTkxM2RjIE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBTdGV2ZSBGaW5rIDxzcGhpbmtAZ21haWwuY29tPgpEYXRlOiBXZWQsIDI5IEphbiAyMDI1IDIyOjEzOjMxIC0wODAwClN1YmplY3Q6IFtQQVRDSF0gSGVhZGVyIGNoYW5nZQoKLS0tCiBqcy9wdWJsaWMvUHJvZmlsaW5nU3RhY2suaCB8IDEgKwoganMvc3JjL3ZtL0dlY2tvUHJvZmlsZXIuaCAgfCAyICsrCiAyIGZpbGVzIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2pzL3B1YmxpYy9Qcm9maWxpbmdTdGFjay5oIGIvanMvcHVibGljL1Byb2ZpbGluZ1N0YWNrLmgKaW5kZXggYjliOTZjMjdkYzFiYi4uOGQ1YzAyN2FkMDI2ZCAxMDA2NDQKLS0tIGEvanMvcHVibGljL1Byb2ZpbGluZ1N0YWNrLmgKKysrIGIvanMvcHVibGljL1Byb2ZpbGluZ1N0YWNrLmgKQEAgLTgsNiArOCw3IEBACiAjZGVmaW5lIGpzX1Byb2ZpbGluZ1N0YWNrX2gKIAogI2luY2x1ZGUgIm1vemlsbGEvQXRvbWljcy5oIgorI2luY2x1ZGUgIm1vemlsbGEvQmFzZVByb2ZpbGVyTWFya2Vyc1ByZXJlcXVpc2l0ZXMuaCIKIAogI2luY2x1ZGUgPHN0ZGludC5oPgogCmRpZmYgLS1naXQgYS9qcy9zcmMvdm0vR2Vja29Qcm9maWxlci5oIGIvanMvc3JjL3ZtL0dlY2tvUHJvZmlsZXIuaAp