[vwnc] Need help understanding fixed-space allocation failures

In testing 7.7, I've been seeing occasional FixedSpace allocation
failures. I need help to understand why these are happening.

Here's an example:

The allocation that fails is:

   UninterpretedBytes newInFixedSpace: 25

Which wants to allocate 25 bytes. But I get a walkback "No space
available to allocate this object".

When I look at ObjectMemory current, I see that there is plenty of space
in FixedSpace:

FIXED: 1.52M / 4.82M, 25

...more than 3MB left, and only 25 objects in fixed space, so it's not
possible that things are fragmented enough that the smallest free space
is less than 25 bytes.

So... did GC run and free up a bunch of memory between the failure and
my looking at memory stats? No, because

   UninterpretedBytes newInFixedSpace: 25

*still* fails.

Something seems very wrong here, but I don't know which things are
wrong. Any explanations or hints for further debugging?

Regards,

-Martin



The full ObjectMemory current and CurrentMemoryPolicy in use:

self:  an ObjectMemory
statistics:
SPACE: used / total[ @ threshold][, objects]

EDEN: 248.91K / 300.00K @ 296.00K
SURVIVOR: 33.78K / 60.00K @ 40.00K
LARGE: 114.56K / 200.00K @ 180.46K, 5
OLD: 4.62M / 34.39M @ 29.77M, 724334
PERM: 10.55M / 15.39M, 423043
FIXED: 1.52M / 4.82M, 25
allocFailures:  1
allocMatches:  0
allocProbes:  59
allocSplits:  10
availableFreeOldSpaceBytes:  4847828
availableFreeOldSpaceBytesLimit:  4838148
bytesPerFTE:  20
bytesPerLTE:  20
bytesPerOOP:  4
bytesPerOTE:  12
bytesPerRTE:  4
compCodeCacheBytes:  655360
contiguousFreeOldBytes:  5230380
edenBytes:  307200
edenUsedBytes:  254888
edenUsedBytesScavengeThreshold:  303104
enumerationCallsPerMillisecond:  197277
fixedBytes:  5062404
fixedSegments:  5
fixedUsedBytes:  1596480
fixedUsedObjects:  25
incGCState:  $r "16r0072"
incMarkedBytes:  0
incMarkedObjects:  0
incMarkedWeakBytes:  0
incMarkedWeakObjects:  0
incNilledBytes:  0
incNilledObjects:  0
incReclaimedBytes:  0
incReclaimedObjects:  0
incSweepAllocatedBytes:  4696
incSweepAllocatedObjects:  11
incSweptObjects:  0
incUnmarkedObjects:  0
largeBytes:  204800
largeFreeBytesTenuringThreshold:  20000
largeUsedBytes:  117312
largeUsedObjects:  5
maximalFreeOldSpaceBytes:  1462228
nativeStackSpills:  15651
numDataCompactions:  33
numGCs:  17
numGlobalGCs:  3
numIncGCs:  756
numMarkStackOverflows:  0
numScavenges:  115110
numWeakObjectListOverflows:  0
oldBytes:  36064640
oldDataBytes:  22142252
oldOTEs:  724334
oldRtEntries:  11000
oldRtUsedEntries:  10855
oldSegments:  14
permBytes:  16146916
permDataBytes:  11069832
permOTEs:  423043
reservedContiguousFreeBytes:  409600
rtEntries:  5000
rtUsedEntries:  73
stackBytes:  40960
survBytes:  61440
survUsedBytes:  34596
survUsedBytesTenuringThreshold:  40960
threadedDataBytes:  27048
threadedDataEntries:  3
threadedOTEntries:  1
1:  19935164
2:  541872
3:  13432668
4:  1003476
5:  83368
6:  3036
7:  1003476
8:  28132
9:  665888
10:  1003476
11:  36240
12:  568588
13:  1003476
14:  1391
15:  986768
16:  1003476
17:  2110
18:  978132
19:  1003476
20:  502
21:  997448
22:  1003476
23:  780
24:  994100
25:  1003476
26:  6951
27:  920064
28:  3629012
29:  17406
30:  2568312
31:  1003476
32:  5572
33:  0
34:  1003476
35:  0
36:  0
37:  1003476
38:  10
39:  27248
40:  1462228
41:  0
42:  0
43:  1048468
44:  13
45:  798304
46:  249872
47:  1003484
48:  1
49:  0
50:  1003464
51:  1003484
52:  7
53:  548072
54:  255788
55:  1003484
56:  3
57:  250024
58:  505784
59:  1003484
60:  1
61:  0
62:  1003464


=====================

self:  a MemoryPolicy
availableSpaceSafetyMargin:  421184
contiguousSpaceSafetyMargin:  50000
freeMemoryUpperBound:  8388608
growthRegimeMeasurementBlock:  BlockClosure [] in
MemoryPolicy>>measureDynamicFootprintForGrowthRegime
growthRegimeUpperBound:  48000000
growthRetryDecrement:  10000
idleLoopAllocationThreshold:  16000000
incGCAccelerationFactor:  5
incMarkingRate:  40
incNillingRate:  2
incrementalAllocationThreshold:  10000
incSweepingRate:  8
incUnmarkingRate:  8
lowSpacePercent:  25
maxHardLowSpaceLimit:  250000
maxPercentOfThreadedData:  75
maxPercentOfThreadedOTEs:  10
maxProbesPerAttempt:  10
memoryMeasurementBlock:  BlockClosure [] in
MemoryPolicy>>measureDynamicFootprintForMemoryUpperBound
memoryStatus:  an ObjectMemory
memoryUpperBound:  536870912
preferredGrowthIncrement:  1000000
threadedDataIncrement:  25000


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jan 21, 2010, at 4:22 PM, Martin McClure wrote:

There *used* to be a bug in the memory policy/VM interface, where it  
was computing free fixed space incorrectly, and coming to the wrong  
conclusion about whether it could allocate or not. I thought that was  
fixed though. I must say, this reminds me of exactly the type of  
problem we had had with it at Key though.

--
Travis Griggs
Objologist
"HTTP. It's like a bike pretending to be a bus, a bulldozer, and a cup  
of coffee at the same time." - Martin Kobetic


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc