issue-409687bd6fd1494ef097bcbd40d8af57bb256eb0.yaml

--- !ditz.rubyforge.org,2008-03-06/issue 
title: "more gc flexibility: mark-and-sweep w/o finalizers, run pending finalizers only, postpone finalization in general"
desc: |-
  In some semi-realtime applications it would useful to be able to:
  
  - Run mark-and-sweep pass without finalization (this is easy because
    Duktape already does this internally).
  
  - Run only pending mark-and-sweep finalizations without running a
    mark-and-sweep pass.
  
  - Postpone refcount-zero finalizer execution to a user controlled moment.
  
  - Execute pending finalizers in small batches (instead of all at the
    same time).
  
  In general it would be nice if finalizer execution was decoupled from
  mark-and-sweep and refcount-zero handling to some extent.  For mark-and-sweep
  this would have the benefit that emergency GC could be executed while
  pending finalizers are being executed.
  
  Incremental GC would be a nice thing in general, but would require a major
  rewrite.
type: :task
component: duk
release: v1.2
reporter: Sami Vaarala <sami.vaarala@iki.fi>
status: :unstarted
disposition: 
creation_time: 2014-09-18 19:41:29.355425 Z
references: []

id: 409687bd6fd1494ef097bcbd40d8af57bb256eb0
log_events: 
- - 2014-09-18 19:41:29.536894 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - created
  - ""
- - 2014-09-18 20:09:24.283700 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - commented
  - |-
    One use case is as follows:
    
    - Mark-and-sweep without finalizers is executed by a background thread in
      an application.  It is important to postpone finalizer execution because
      if finalizers were executed, they would interact with other threads in
      the application, requiring thread safety in the application code.
    
      While mark-and-sweep runs, the application makes no Duktape calls from
      other threads, so there is no threading conflict here.
    
    - The "main thread" of the application can then run the pending finalizers
      when it has time.
    
    This is useful because a majority of the "stop-and-go" problem is moved to
    a background thread.  Only finalizer execution, which is somewhat rare and
    much less intensive than mark-and-sweep is executed in the main thread.
    
    Further, if it were possible to run pending finalizers one at a time, it
    would be even easier to control the maximum blocking time of the application's
    main thread.
- - 2014-11-02 00:19:59.194556 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - assigned to release v1.2 from v1.1
  - ""