594756 - Conservative marking of large objects should pay attention to AskSize

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect)

Description

[Lars T Hansen]

Most large objects are probably fairly small, because our large-object cutoff is quite small (less than 2KB).  Yet the tracer scans all the allocated storage for a large object, that is, an integral number of blocks minus the large object header.  That isn't really the tracer's fault; it's GCLargeAlloc::Alloc that sets up the size field of the large object to cover that entire area.  But it's likely that we could reduce the scanning work for large objects by recording a size closer to the request size.

Comment 1

[Tommy Reilly]

+1 we even have 4 unused bytes of padding to play with on 32 bit systems.    What if the mutator calls Size() and starts using all the space?   I suggested to Ed that we could make the askSize == totalSize if Size was ever called and I think he almost threw up.   The argument was Size should be a const API and not change anything.   I don't fully buy that but I do agree a better API would be nice (ie size_t ResizeToCapacity(void*) or something).   But currently we have code that calls Size and assumes they can use that many bytes so we'd have to be careful.

Comment 2

[Lars T Hansen]

If that's the API for large objects, is it also the API for small objects?  I would assume "yes".

(My nausea level is comparable to Ed's re your first suggestion but I want to keep my options open...)

Comment 3

[Edwin Smith]

I think I also conjured up an exact tracing argument:

  MyObject** p = gc->Alloc(7*sizeof(ptr));
  p[0..6] = /* valid ptr */  
  // here, p[0..6] must be traced.
  // here, access to p[7] is a mutator bug.
  print(gc->Size(p)); // returns 8
  // here, p[0..7] must be traced.  what is p[7] initialized to?
  // here, access to p[7] is no longer a bug?

thus: calling Size() is like calling realloc().  bleh
Do any of the rules change for, say, 7000 vs 7?  is there an API to query the threshold? bleh, again.

Comment 4

[Tommy Reilly]

There's another way out of this, provide something like malloc_good_size, the idea is you do this:

size = GC::AllocGoodSize(size);
gc->Alloc(size);

the idea is classes like list that want to take full advantage of the memory they get can prefetch what the capacity will be for a given size class.

Comment 5

[Lars T Hansen]

(In reply to comment #3)
> I think I also conjured up an exact tracing argument:
> 
>   MyObject** p = gc->Alloc(7*sizeof(ptr));
>   p[0..6] = /* valid ptr */  
>   // here, p[0..6] must be traced.
>   // here, access to p[7] is a mutator bug.
>   print(gc->Size(p)); // returns 8
>   // here, p[0..7] must be traced.  what is p[7] initialized to?
>   // here, access to p[7] is no longer a bug?

That's not true: what it means to trace an object exactly is defined by the code that allocated the object, and not by MMgc (which ignores all information it has about the object's layout).

Comment 6

[Lars T Hansen]

This seems like a boondoggle best avoided by (a) moving to exact tracing where we can and (b) increasing the upper limit on "small" objects.

I'm going to keep it open for now so that this information is not lost, though.