Fifth IEEE International Workshop on Source Code Analysis and Manipulation (SCAM'05)
DOI: 10.1109/scam.2005.1
|View full text |Cite
|
Sign up to set email alerts
|

A Fast Analysis for Thread-Local Garbage Collection with Dynamic Class Loading

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
3
1
1

Citation Types

0
10
0

Publication Types

Select...
4
3
1

Relationship

0
8

Authors

Journals

citations
Cited by 19 publications
(10 citation statements)
references
References 28 publications
0
10
0
Order By: Relevance
“…Local and newly instantiated objects are allocated in thread-specific heaplets since they are, for high probability, accessed by the thread itself [8,25,19,1,16,2]. Furthermore, heaplets can be collected independently since objects are local and no need to synchronize all mutator threads.…”
Section: Related Workmentioning
confidence: 99%
“…Local and newly instantiated objects are allocated in thread-specific heaplets since they are, for high probability, accessed by the thread itself [8,25,19,1,16,2]. Furthermore, heaplets can be collected independently since objects are local and no need to synchronize all mutator threads.…”
Section: Related Workmentioning
confidence: 99%
“…Static analyses overestimate the number of objects actually shared. Most are conservative in the face of (or ignore) dynamic class loading; Jones & King [15] use an optimistic, and hence more precise, analysis that falls back at run-time to more conservative assumptions should a dynamically loaded class invalidate parts of a prior analysis. Runtime analysis delivers more precise results but requires read or write barriers to detect escape [17].…”
Section: Shared-used and Shared-reachable Objectsmentioning
confidence: 99%
“…Thread-local heaps enforce local access to thread-specific objects [2,7,14,18,28]. New objects are initially allocated in thread-local heaps until they are referenced by non-local objects.…”
Section: Related Workmentioning
confidence: 99%