Permalink
Browse files

Don't reset ticks on GC_TICKS so that MAX_TICKS will hit.

By resetting on GC_TICKS, MAX_TICKS was never reached because it is
always larger than GC_TICKS. So we use a modulo check now. We still
reset MAX_TICKS to 0, since that should be larger.
  • Loading branch information...
1 parent c1a4e49 commit e4fb7337204636973aaedec36809be51e1d5cba2 @mitchellh committed Jun 22, 2012
Showing with 4 additions and 3 deletions.
  1. +1 −0 CHANGELOG.md
  2. +3 −3 apps/lifeguard/src/lifeguard_js_vm.erl
View
@@ -8,6 +8,7 @@ Bugs fixed:
- Seed the random number generator so we can generate more than 22 UUIDs.
- Create watch API responds with proper "Location" header set.
+ - V8 VMs will recycle themselves properly after MAX_TICKS.
## 0.1.1 (June 21, 2012)
@@ -9,7 +9,7 @@
% The number of watches we run before we recycle the entire
% V8 VM just in case there are memory leaks.
--define(MAX_TICKS, 32768).
+-define(MAX_TICKS, 1024).
% The maximum depth that the JS to Erlang conversion recurses until
% it throws an error.
@@ -184,12 +184,12 @@ increment_ticks(State) ->
init_vm_globals(VM),
State#vm_state{vm=VM, ticks=0};
- NewTicks >= ?GC_TICKS ->
+ NewTicks rem ?GC_TICKS =:= 0 ->
% The GC_TICKS are reached, which is our limit before we
% invoke the GC.
lager:debug("VM ~p GC_TICKS reached. GC running.", [State#vm_state.id]),
erlv8_vm:gc(State#vm_state.vm),
- State#vm_state{ticks=0};
+ State#vm_state{ticks=NewTicks};
true ->
% Otherwise, just increment the ticks

0 comments on commit e4fb733

Please sign in to comment.