archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-09-19 10:34:38 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

7133260: AllocationProfiler uses space in metadata and doesn't seem to do anything useful

Browse source 
Remove -Xaprof and Klass::_alloc_count & ArrayKlass::_alloc_size.

Reviewed-by: stefank, coleenp
This commit is contained in:
Jiangli Zhou 2013-07-03 17:26:59 -04:00
parent 4ecee47075
commit b454ece6d7
30 changed files with 7 additions and 388 deletions
Download patch file Download diff file Expand all files Collapse all files

6
hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
View file

@ -2017,12 +2017,6 @@ oop_since_save_marks_iterate##nv_suffix(OopClosureType* blk) { \
ALL_SINCE_SAVE_MARKS_CLOSURES(CFLS_OOP_SINCE_SAVE_MARKS_DEFN)
void CompactibleFreeListSpace::object_iterate_since_last_GC(ObjectClosure* cl) {
// ugghh... how would one do this efficiently for a non-contiguous space?
guarantee(false, "NYI");
}
bool CompactibleFreeListSpace::linearAllocationWouldFail() const {
return _smallLinearAllocBlock._word_size == 0;
}

1
hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
View file

@ -396,7 +396,6 @@ class CompactibleFreeListSpace: public CompactibleSpace {
// iteration support for promotion
void save_marks();
bool no_allocs_since_save_marks();
void object_iterate_since_last_GC(ObjectClosure* cl);
// iteration support for sweeping
void save_sweep_limit() {

20
hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
View file

@ -3129,26 +3129,6 @@ oop_since_save_marks_iterate##nv_suffix(OopClosureType* cl) { \
ALL_SINCE_SAVE_MARKS_CLOSURES(CMS_SINCE_SAVE_MARKS_DEFN)
void
ConcurrentMarkSweepGeneration::object_iterate_since_last_GC(ObjectClosure* blk)
{
// Not currently implemented; need to do the following. -- ysr.
// dld -- I think that is used for some sort of allocation profiler. So it
// really means the objects allocated by the mutator since the last
// GC. We could potentially implement this cheaply by recording only
// the direct allocations in a side data structure.
//
// I think we probably ought not to be required to support these
// iterations at any arbitrary point; I think there ought to be some
// call to enable/disable allocation profiling in a generation/space,
// and the iterator ought to return the objects allocated in the
// gen/space since the enable call, or the last iterator call (which
// will probably be at a GC.) That way, for gens like CM&S that would
// require some extra data structure to support this, we only pay the
// cost when it's in use...
cmsSpace()->object_iterate_since_last_GC(blk);
}
void
ConcurrentMarkSweepGeneration::younger_refs_iterate(OopsInGenClosure* cl) {
cl->set_generation(this);

1
hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
View file

@ -1273,7 +1273,6 @@ class ConcurrentMarkSweepGeneration: public CardGeneration {
// Iteration support and related enquiries
void save_marks();
bool no_allocs_since_save_marks();
void object_iterate_since_last_GC(ObjectClosure* cl);
void younger_refs_iterate(OopsInGenClosure* cl);
// Iteration support specific to CMS generations