Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 3.2
-
Component/s: Infrastructure: Test
-
Labels:None
Description
A very minor casualty in the last few months of cleanup is the appended code in InlineAllocation.java. What the test is trying to do is to have tighter bounds on the allowable code space for bump pointer allocators than for segregated free list allocators. Somewhere along the way, we lost the connection between the GC configuration and the test itself.
There are probably a number of ways to fix this; we don't particuarly need the VM_Configuration flag, just some way for the test to ask the VM whether or not it is using a bump pointer allocator.
// Limits on sizes of allocation sequences.
// Make them specific to the allocator so we can make them reasonably tight.
- static int alloc1Limit = assertionSpace + (VM.BuildWithBumpAllocator ? (VM.BuildForIA32 ? 75 : 22) : (VM.BuildForIA32 ? 100 : 30)); // small object
+ static int alloc1Limit = assertionSpace + (VM.BuildForIA32 ? 100 : 30); // small object
static int alloc2Limit = alloc1Limit + (VM.BuildForIA32 ? 8 : 2); //small array. Should be only the store of the length different than small object
static int alloc3Limit = assertionSpace + (VM.BuildForIA32 ? 100 : 30); // large object
static int alloc4Limit = (VM.BuildForIA32 ? 40 : 11); // unknown size object. Should not be inlined at all.
Looks like the lack of a tight bound on this test has allowed us to pork up the inline allocation sequence again. Need to fix the test so that we catch these performance problems when they get introduced, not when we happen to have another bug that happens to include an allocation sequence so we get lucky and notice...