JDK-6994322 : Remove the is_tlab and is_noref / is_large_noref parameters from the CollectedHeap interface
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs20
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-10-22
  • Updated: 2011-11-25
  • Resolved: 2011-09-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u2Fixed 8Fixed hs22Fixed
Related Reports
Relates :  
JDK-6974966 - G1: unnecessary direct-to-old allocations
Description
The mem_allocate() method in the CollectedHeap class (and in all the GCs it has been implemented in) takes two parameteres, is_tlab and is_large_noref, that do not seem to be used.

- is_tlab : this indicates whether the allocation is for a TLAB or not. It looks as if this interface is not used anymore and it has been replaced with the explicit allocate_new_tlab() method.

- is_noref : (it's also eferred to as is_large_noref in the GenCollectedHeap) it indicates that the allocation request is for a large object that has no references. This was probably used by the Train GC which has now been removed from the HotSpot codebase and it's ignored by all other GCs. G1 does allocate large objects through a special path, but it can't take advantage of this particular parameter given that the parameter only identifies large scalar arrays, not all large arrays.

I should also point out that, while working on 6974966, I did fair amount of testing asserting !is_tlab in the mem_allocate() method with no failures encountered.
Comments
EVALUATION See main CR
12-09-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c9ca3f51cf41
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c9ca3f51cf41
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c9ca3f51cf41
17-06-2011
EVALUATION After removing those two parameters, we can do some further clean up. * CollectedHeap: - We can remove the large_typearray_limit() method and all its implementations, given that it was only used to determine whether is_noref should be set to true or not. - We can remove the is_noref parameter from the CollectedHeap::common_mem_allocate_init() and CollectedHeap::commit_mem_allocate_noinit() methods. * GenCollectedHeap: In GenCollectedHeaop allocate_new_tlab() actually calls mem_allocate() with is_tlab set to true. This can be changed so that allocate_new_tlab() calls collector_policy()->mem_allocate_work() instead with is_tlab set to true (what mem_allocate() ultimately calls anyway). * G1: The changes for 6974966 already ensured that G1 ignores the is_tlab parameter and it has never used the is_noref parameter (it checks explicitly in mem_allocate() to identify humongous objects). So, the changes in G1 are minimal. * ParallelScavenge: ParallelScavenge (PS) has more opportunities to remove dead code / parameters than the other two. It looks as if the is_tlab parameter is passed from method to method without actually being used. In fact, it can be assumed that the parameter is always false given that the calls to all the methods that accept an is_tlab parameter start from mem_allocate() which can never be used to allocate TLABs (ParallelScavengeHeap::allocate_new_tlab() just does an allocation attempt in the eden space). Here's where an is_tlab parameter is used in PS and why it can be removed from all these places: - VM_ParallelGCFailedAllocation::VM_ParallelGCFailedAllocation(size_t size, bool is_tlab, unsigned int gc_count) (the VM_ParallelGCFailedAllocation class also has an _is_tlab field) This VM operation can only be scheduled from the mem_allocate() method which cannot be used for non-TLAB allocation requests. So, is_tlab can only be false and any allocation attempts within the VM operation will not be for a TLAB allocation. - HeapWord* ParallelScavengeHeap::failed_mem_allocate(size_t size, bool is_tlab) Only called from VM_ParallelGCFailedAllocation::doit() which, as shown earlier, is only initiated from mem_allocate() for non-TLAB allocation requests. This is the only place where _is_tlab is used. - HeapWord* PSYoungGen::allocate(size_t word_size, bool is_tlab) The parameter is ignored in the body of the method. - HeapWord* PSOldGen::allocate_noexpand(size_t word_size, bool is_tlab) - HeapWord* PSOldGen::expand_and_allocate(size_t word_size, bool is_tlab) - HeapWord* PSOldGen::allocate(size_t word_size, bool is_tlab) allocate() calls allocate_noexpand() and/or expand_and_allocate(). Both allocate_noexpand() and expand_and_allocate() assert !is_tlab claiming that TLAB allocations are not support in the old gen (and correctly so). - HeapWord* PSPermGen::allocate_permanent(size_t size) It calls PSOldGen::allocate_noexpand() and/or PSOldGen::expand_and_allocate() with is_tlab == false.
22-10-2010