chore: Add issue references (#226)

Author: elliottt

c-dependencies/js-compute-runtime/builtins/fastly.cpp

@@ -63,6 +63,7 @@ bool Fastly::getGeolocationForIpAddress(JSContext *cx, unsigned argc, JS::Value
 
 // TODO(performance): consider allowing logger creation during initialization, but then throw
 // when trying to log.
+// https://github.com/fastly/js-compute-runtime/issues/225
 bool Fastly::getLogger(JSContext *cx, unsigned argc, JS::Value *vp) {
   JS::CallArgs args = CallArgsFromVp(argc, vp);
   REQUEST_HANDLER_ONLY("fastly.getLogger");

c-dependencies/js-compute-runtime/js-compute-builtins.cpp

@@ -123,6 +123,7 @@ static JS::PersistentRootedObjectVector *pending_body_reads;
 
 // TODO(performance): introduce a version that writes into an existing buffer, and use that
 // with the hostcall buffer where possible.
+// https://github.com/fastly/js-compute-runtime/issues/215
 UniqueChars encode(JSContext *cx, HandleString str, size_t *encoded_len) {
   UniqueChars text = JS_EncodeStringToUTF8(cx, str);
   if (!text)
@@ -197,8 +198,10 @@ static char *read_from_handle_all(JSContext *cx, HandleType handle, size_t *nwri
                                   bool read_until_zero) {
   // TODO(performance): investigate passing a size hint in situations where we might know
   // the final size, e.g. via the `content-length` header.
+  // https://github.com/fastly/js-compute-runtime/issues/216
   size_t buf_size = HANDLE_READ_CHUNK_SIZE;
   // TODO(performance): make use of malloc slack.
+  // https://github.com/fastly/js-compute-runtime/issues/217
   char *buf = static_cast<char *>(JS_malloc(cx, buf_size));
   if (!buf) {
     JS_ReportOutOfMemory(cx);
@@ -223,6 +226,7 @@ static char *read_from_handle_all(JSContext *cx, HandleType handle, size_t *nwri
     }
 
     // TODO(performance): make use of malloc slack, and use a smarter buffer growth strategy.
+    // https://github.com/fastly/js-compute-runtime/issues/217
     size_t new_size = buf_size + HANDLE_READ_CHUNK_SIZE;
     new_buf = static_cast<char *>(JS_realloc(cx, buf, buf_size, new_size));
     if (!new_buf) {
@@ -740,6 +744,7 @@ bool bodyAll(JSContext *cx, CallArgs args, HandleObject self) {
   // we need to manually read all chunks from the stream.
   // TODO(performance): ensure that we're properly shortcutting reads from TransformStream
   // readables.
+  // https://github.com/fastly/js-compute-runtime/issues/218
   RootedObject stream(cx, body_stream(self));
   if (stream && !builtins::NativeStreamSource::stream_is_body(cx, stream)) {
     if (!consume_content_stream_for_bodyAll(cx, self, stream, body_parser)) {
@@ -2148,8 +2153,10 @@ bool constructor(JSContext *cx, unsigned argc, Value *vp) {
   // e.g. to represent cache entries. While that's perhaps not ideal to begin
   // with, it exists, so we should handle it in a good way, and not be
   // superfluously slow.
+  // https://github.com/fastly/js-compute-runtime/issues/219
   // TODO(performance): enable creating Response objects during the init phase, and only
   // creating the host-side representation when processing requests.
+  // https://github.com/fastly/js-compute-runtime/issues/220
   ResponseHandle response_handle = {.handle = INVALID_HANDLE};
   if (!HANDLE_RESULT(cx, xqd_resp_new(&response_handle))) {
     return false;
@@ -2926,6 +2933,7 @@ bool append(JSContext *cx, unsigned argc, Value *vp) {
  *
  * Assumes that both the name and value are valid and normalized.
  * TODO(performance): fully skip normalization.
+ * https://github.com/fastly/js-compute-runtime/issues/221
  */
 bool maybe_add(JSContext *cx, HandleObject self, const char *name, const char *value) {
   MOZ_ASSERT(is_instance(self));

c-dependencies/js-compute-runtime/js-compute-runtime.cpp

@@ -273,6 +273,7 @@ bool eval_stdin(JSContext *cx, MutableHandleValue result) {
   // by parsing the script (but not evaluating it) tend to be read-only, so
   // optimizing them for compactness makes sense and doesn't fragment writes
   // later on.
+  // https://github.com/fastly/js-compute-runtime/issues/222
   JS::PrepareForFullGC(cx);
   JS::NonIncrementalGC(cx, JS::GCOptions::Shrink, JS::GCReason::API);
 
@@ -300,6 +301,7 @@ bool eval_stdin(JSContext *cx, MutableHandleValue result) {
   // running GC like this. The working theory is that otherwise the engine might
   // mark chunk pages as free that then later the allocator doesn't turn into
   // chunks without further fragmentation. But that might be wrong.
+  // https://github.com/fastly/js-compute-runtime/issues/223
   // JS_SetGCParameter(cx, JSGC_MAX_EMPTY_CHUNK_COUNT, 10);
 
   // TODO(performance): verify that it's better to *not* perform a shrinking GC here, as
@@ -311,6 +313,7 @@ bool eval_stdin(JSContext *cx, MutableHandleValue result) {
   // object kinds that are initially allocated in the same vicinity, but that
   // the shrinking GC causes them to be intermingled with other objects. I.e.,
   // writes become more fragmented due to the shrinking GC.
+  // https://github.com/fastly/js-compute-runtime/issues/224
   JS::PrepareForFullGC(cx);
   JS::NonIncrementalGC(cx, JS::GCOptions::Normal, JS::GCReason::API);