# Boehm-Demers-Weiser Garbage Collector
[![Travis-CI build status](https://travis-ci.org/ivmai/bdwgc.svg?branch=master)](https://travis-ci.org/ivmai/bdwgc)
[![AppVeyor CI build status](https://ci.appveyor.com/api/projects/status/github/ivmai/bdwgc?branch=master&svg=true)](https://ci.appveyor.com/project/ivmai/bdwgc)
[![Coveralls test coverage status](https://coveralls.io/repos/github/ivmai/bdwgc/badge.png?branch=master)](https://coveralls.io/github/ivmai/bdwgc)
[![Coverity Scan build status](https://scan.coverity.com/projects/10813/badge.svg)](https://scan.coverity.com/projects/ivmai-bdwgc)
This is version 7.7.0 (next release development) of a conservative garbage
collector for C and C++.
## Download
You might find a more recent/stable version on the
[Download](https://github.com/ivmai/bdwgc/wiki/Download) page, or
[BDWGC site](http://www.hboehm.info/gc/).
Also, the latest bug fixes and new features are available in the
[development repository](https://github.com/ivmai/bdwgc).
## Overview
This is intended to be a general purpose, garbage collecting storage
allocator. The algorithms used are described in:
* Boehm, H., and M. Weiser, "Garbage Collection in an Uncooperative
Environment", Software Practice & Experience, September 1988, pp. 807-820.
* Boehm, H., A. Demers, and S. Shenker, "Mostly Parallel Garbage Collection",
Proceedings of the ACM SIGPLAN '91 Conference on Programming Language Design
and Implementation, SIGPLAN Notices 26, 6 (June 1991), pp. 157-164.
* Boehm, H., "Space Efficient Conservative Garbage Collection", Proceedings
of the ACM SIGPLAN '91 Conference on Programming Language Design and
Implementation, SIGPLAN Notices 28, 6 (June 1993), pp. 197-206.
* Boehm H., "Reducing Garbage Collector Cache Misses", Proceedings of the
2000 International Symposium on Memory Management.
Possible interactions between the collector and optimizing compilers are
discussed in
* Boehm, H., and D. Chase, "A Proposal for GC-safe C Compilation",
The Journal of C Language Translation 4, 2 (December 1992).
and
* Boehm H., "Simple GC-safe Compilation", Proceedings of the ACM SIGPLAN '96
Conference on Programming Language Design and Implementation.
Unlike the collector described in the second reference, this collector
operates either with the mutator stopped during the entire collection
(default) or incrementally during allocations. (The latter is supported
on fewer machines.) On the most common platforms, it can be built
with or without thread support. On a few platforms, it can take advantage
of a multiprocessor to speed up garbage collection.
Many of the ideas underlying the collector have previously been explored
by others. Notably, some of the run-time systems developed at Xerox PARC
in the early 1980s conservatively scanned thread stacks to locate possible
pointers (cf. Paul Rovner, "On Adding Garbage Collection and Runtime Types
to a Strongly-Typed Statically Checked, Concurrent Language" Xerox PARC
CSL 84-7). Doug McIlroy wrote a simpler fully conservative collector that
was part of version 8 UNIX (tm), but appears to not have received
widespread use.
Rudimentary tools for use of the collector as a
[leak detector](doc/leak.md) are included,
as is a fairly sophisticated string package "cord" that makes use of the
collector. (See doc/README.cords and H.-J. Boehm, R. Atkinson, and M. Plass,
"Ropes: An Alternative to Strings", Software Practice and Experience 25, 12
(December 1995), pp. 1315-1330. This is very similar to the "rope" package
in Xerox Cedar, or the "rope" package in the SGI STL or the g++ distribution.)
Further collector documentation can be found in the
[overview](doc/overview.md).
## General Description
This is a garbage collecting storage allocator that is intended to be
used as a plug-in replacement for C's malloc.
Since the collector does not require pointers to be tagged, it does not
attempt to ensure that all inaccessible storage is reclaimed. However,
in our experience, it is typically more successful at reclaiming unused
memory than most C programs using explicit deallocation. Unlike manually
introduced leaks, the amount of unreclaimed memory typically stays
bounded.
In the following, an "object" is defined to be a region of memory allocated
by the routines described below.
Any objects not intended to be collected must be pointed to either
from other such accessible objects, or from the registers,
stack, data, or statically allocated bss segments. Pointers from
the stack or registers may point to anywhere inside an object.
The same is true for heap pointers if the collector is compiled with
`ALL_INTERIOR_POINTERS` defined, or `GC_all_interior_pointers` is otherwise
set, as is now the default.
Compiling without `ALL_INTERIOR_POINTERS` may reduce accidental retention
of garbage objects, by requiring pointers from the heap to the beginning
of an object. But this no longer appears to be a significant
issue for most programs occupying a small fraction of the possible
address space.
There are a number of routines which modify the pointer recognition
algorithm. `GC_register_displacement` allows certain interior pointers
to be recognized even if `ALL_INTERIOR_POINTERS` is nor defined.
`GC_malloc_ignore_off_page` allows some pointers into the middle of
large objects to be disregarded, greatly reducing the probability of
accidental retention of large objects. For most purposes it seems
best to compile with `ALL_INTERIOR_POINTERS` and to use
`GC_malloc_ignore_off_page` if you get collector warnings from
allocations of very large objects. See [here](doc/debugging.md) for details.
_WARNING_: pointers inside memory allocated by the standard `malloc` are not
seen by the garbage collector. Thus objects pointed to only from such a
region may be prematurely deallocated. It is thus suggested that the
standard `malloc` be used only for memory regions, such as I/O buffers, that
are guaranteed not to contain pointers to garbage collectible memory.
Pointers in C language automatic, static, or register variables,
are correctly recognized. (Note that `GC_malloc_uncollectable` has
semantics similar to standard malloc, but allocates objects that are
traced by the collector.)
_WARNING_: the collector does not always know how to find pointers in data
areas that are associated with dynamic libraries. This is easy to
remedy IF you know how to find those data areas on your operating
system (see `GC_add_roots`). Code for doing this under SunOS, IRIX
5.X and 6.X, HP/UX, Alpha OSF/1, Linux, and win32 is included and used
by default. (See doc/README.win32 for Win32 details.) On other systems
pointers from dynamic library data areas may not be considered by the
collector. If you're writing a program that depends on the collector
scanning dynamic library data areas, it may be a good idea to include
at least one call to `GC_is_visible` to ensure that those areas are
visible to the collector.
Note that the garbage collector does not need to be informed of shared
read-only data. However if the shared library mechanism can introduce
discontiguous data areas that may contain pointers, then the collector does
need to be informed.
Signal processing for most signals may be deferred during collection,
and during uninterruptible parts of the allocation process.
Like standard ANSI C mallocs, by default it is unsafe to invoke
malloc (and other GC routines) from a signal handler while another
malloc call may be in progress.
The allocator/collector can also be configured for thread-safe operation.
(Full signal safety can also be achieved, but only at the cost of two system
calls per malloc, which is usually unacceptable.)
_WARNING_: the collector does not guarantee to scan thread-local storage
(e.g. of the kind accessed with `pthread_getspecific`). The collector
does scan thread stacks, though, so generally the best solution is to
ensure that any pointers stored in thread-local storage are als
没有合适的资源?快使用搜索试试~ 我知道了~
将Addressable加入华佗热更新方案
共6413个文件
dll:3017个
h:1434个
cpp:940个
需积分: 36 19 下载量 168 浏览量
2022-09-30
10:18:25
上传
评论
收藏 87.07MB 7Z 举报
温馨提示
将Addressable加入华佗热更新方案
资源详情
资源评论
资源推荐
收起资源包目录
将Addressable加入华佗热更新方案 (6413个子文件)
2020.3.33 188B
2020.3.33 41B
Android 1022B
HotFix.asmdef 506B
App.asmdef 419B
DefaultWsdlHelpGenerator.aspx 59KB
DefaultWsdlHelpGenerator.aspx 59KB
DefaultWsdlHelpGenerator.aspx 59KB
ProjectSettings.asset 21KB
QualitySettings.asset 6KB
InputManager.asset 6KB
AddressableAssetSettings.asset 4KB
GraphicsSettings.asset 2KB
Packed Assets.asset 2KB
Physics2DSettings.asset 2KB
Default Local Group_BundledAssetGroupSchema.asset 2KB
NavMeshAreas.asset 1KB
DynamicsManager.asset 1KB
EditorUserSettings.asset 1KB
Default Local Group.asset 1KB
PackageManagerSettings.asset 1002B
UnityConnectSettings.asset 1002B
EditorSettings.asset 969B
Built In Data.asset 929B
BuildScriptPackedPlayMode.asset 816B
BuildScriptVirtualMode.asset 813B
BuildScriptPackedMode.asset 812B
BuildScriptFastMode.asset 810B
Built In Data_PlayerDataGroupSchema.asset 568B
Default Local Group_ContentUpdateGroupSchema.asset 533B
DefaultObject.asset 469B
AudioManager.asset 416B
AutoStreamingSettings.asset 379B
TagManager.asset 378B
EditorBuildSettings.asset 355B
VFXManager.asset 308B
TimeManager.asset 202B
VersionControlSettings.asset 188B
XRSettings.asset 158B
PresetManager.asset 146B
ClusterInputManager.asset 114B
init_local_il2cpp_data.bat 2KB
cli.bat 124B
nunit-console.bat 106B
monolinker.bat 95B
resgen2.bat 91B
xbuild.bat 91B
ilasm.bat 90B
mcs.bat 88B
addressables_content_state.bin 2KB
addressables_content_state.bin 1KB
Compat.browser 2KB
Compat.browser 2KB
Compat.browser 2KB
build_info 47B
huatuodata.bundle 979KB
hotfixed.unity.bundle 91KB
defaultlocalgroup_unitybuiltinshaders.bundle 49KB
mscorlib.dll.bytes 1.57MB
mscorlib.dll.bytes 1.56MB
System.dll.bytes 194KB
System.dll.bytes 193KB
System.Core.dll.bytes 28KB
System.Core.dll.bytes 28KB
HotFix.dll.bytes 6KB
marshal.c 356KB
debugger-agent.c 337KB
class.c 334KB
icall.c 256KB
object.c 249KB
verify.c 206KB
metadata.c 201KB
dlmalloc.c 177KB
os_dep.c 171KB
metadata-verify.c 149KB
threads.c 146KB
sre.c 142KB
sgen-gc.c 127KB
w32file-unix.c 127KB
w32process-unix.c 123KB
assembly.c 121KB
cominterop.c 108KB
sre-save.c 107KB
win32_threads.c 102KB
reflection.c 96KB
sgen-marksweep.c 93KB
sgen-mono.c 91KB
image.c 82KB
loader.c 82KB
appdomain.c 81KB
misc.c 81KB
decimal-ms.c 79KB
deflate.c 77KB
pthread_support.c 77KB
mark.c 76KB
custom-attrs.c 73KB
w32socket.c 73KB
test.c 70KB
remoting.c 63KB
boehm-gc.c 57KB
共 6413 条
- 1
- 2
- 3
- 4
- 5
- 6
- 65
越人語天
- 粉丝: 8
- 资源: 5
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0