Fix memory leak caused by treating Code::next_code_link as strong in marker.

test/cctest/test-heap.cc

 // Copyright 2012 the V8 project authors. All rights reserved.
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 //
 //     * Redistributions of source code must retain the above copyright
 //       notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
 //       copyright notice, this list of conditions and the following
 //       disclaimer in the documentation and/or other materials provided
@@ skipping 3670 matching lines @@
     code = scope.CloseAndEscape(Handle<Code>(bar->code()));
   }
 
   // Now make sure that a gc should get rid of the function
   for (int i = 0; i < 4; i++) {
     heap->CollectAllGarbage(Heap::kAbortIncrementalMarkingMask);
   }
 
   ASSERT(code->marked_for_deoptimization());
 }
+
+
+static Handle<JSFunction> OptimizeDummyFunction(const char* name) {
+  char source[256];
+  snprintf(source, sizeof(source),
+           "function %s() { return 0; }"
+           "%s(); %s();"
+           "%%OptimizeFunctionOnNextCall(%s);"
+           "%s();", name, name, name, name, name);
+  CompileRun(source);
+  Handle<JSFunction> fun =
+      v8::Utils::OpenHandle(
+          *v8::Handle<v8::Function>::Cast(
+              CcTest::global()->Get(v8_str(name))));
+  return fun;
+}
+
+
+static int GetCodeChainLength(Code* code) {
+  int result = 0;
+  while (code->next_code_link()->IsCode()) {
+    result++;
+    code = Code::cast(code->next_code_link());
+  }
+  return result;
+}
+
+
+TEST(NextCodeLinkIsWeak) {

[titzer, 2014/03/05 08:58:02]

Why not make a test case that creates optimized code objects and links them
together directly? This test case seems pretty brittle and makes lots of
assumptions about how the compiler links functions and code objects together.

[ulan, 2014/03/06 11:13:32]

It assumes two things:
- next_code_link is used for linking
- the optimized code list is a stack (the last optimized code object points to
the previously optimized code)

Alternative to this would be to manage the list manually. Then I would have to
- optimize the two functions
- remove the optimized code objects from the context[OPTIMIZED_CODE_LIST] list
- add two code objects to the list manually.

I agree that this is less brittle in the sense that it wouldn't break if the
real list management changes. But then there is a risk that the list management
in this test and the real list management diverge and the test no longer tests
the implementation.

+  if (!i::FLAG_crankshaft) return;
+  i::FLAG_allow_natives_syntax = true;
+  CcTest::InitializeVM();
+  Isolate* isolate = CcTest::i_isolate();
+  v8::internal::Heap* heap = CcTest::heap();
+
+  if (!isolate->use_crankshaft()) return;
+  HandleScope outer_scope(heap->isolate());
+  Handle<Code> code;
+  heap->CollectAllAvailableGarbage();
+  int code_chain_length_before, code_chain_length_after;
+  {
+    HandleScope scope(heap->isolate());
+    Handle<JSFunction> mortal = OptimizeDummyFunction("mortal");
+    Handle<JSFunction> immortal = OptimizeDummyFunction("immortal");
+    CHECK_EQ(immortal->code()->next_code_link(), mortal->code());
+    code_chain_length_before = GetCodeChainLength(immortal->code());
+    // Keep the immortal code and let the mortal code die.
+    code = scope.CloseAndEscape(Handle<Code>(immortal->code()));
+    CompileRun("mortal = null; immortal = null;");
+  }
+  heap->CollectAllAvailableGarbage();
+  // Now mortal code should be dead.
+  code_chain_length_after = GetCodeChainLength(*code);
+  CHECK_EQ(code_chain_length_before - 1, code_chain_length_after);
+}