mirror of https://github.com/svaarala/duktape.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
62 lines
2.4 KiB
62 lines
2.4 KiB
--- !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.1
|
|
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.
|
|
|