Le 22/02/2012 20:53, Benjamin Thaut a écrit :
If you have a better idea for percise stack scanning I'm open for
suggestions.
This is the problem with your proposal. It doesn't consider pro and cons
and actual data. It doesn't consider the alternatives. You go straight
to « How can we do that ? » without condidering « should we do that ? »
What would be the impact of being precise on the heap but not on the stack ?
1/ It would add some false positives. The future being 64bits, False
positive will be way less present than on 32bits machines. I did
searched for numbers on that, but couldn't found them. Considering this
is only on the stack, this may be neglectible (or not, but it
definitively require data).
2/ Data pointed by the stack are not movable.Again, what is the impact
of that. How much data could be promoted from young generation to old
one (considering we have young and old gen). How much data couldn't be
compacted ? What would the overhead on allocators ?
This definitively lack the required data and/or analysis of pro and cons.
Additionnaly, the stack is made like a linked list. Each function
calling another one register the return address. With this information,
we can have data about what is on the stack except for the very last
function called with no runtime overhead. This is another alternative.
But you have to consider that, even with a mask, you are not sure that
what is marked as a pointer is a pointer. A memory location can
represent different thing during a function execution. So thoses values
can only be considered as probable pointers, or we disable some compiler
optimizations. As we cannot be sure, the point 2/ stay valid.
Granted the overhead of the operation, it ay not worth it. To know that,
we need actual data on how much data is the stack is actually pointer,
and how much false positive we get. As the future is 64bits, I'm not
sure it is interesting for us.
