archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-08-27 23:04:50 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

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

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);