[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC and stack marking
From: |
Barry OReilly |
Subject: |
Re: GC and stack marking |
Date: |
Thu, 22 May 2014 10:59:00 -0400 |
> Yes. I looked at all the local variables in that stack frame, and
> their addresses on the stack are different from the one that
> triggers the problem.
[I assume you mean "void* values on the stack" rather than "addresses
on the stack".]
So when you printed the value of a one byte variable like
stack_top_variable, you printed it with any alignment padding there
might be?
Or in case of GC_POINTER_ALIGNMENT < sizeof(void*), you accounted for
mark_stack's candidate void* coming partially from different stack
variables?
And you accounted for the compiler reordering stack variables, eg to
more optimally align data? I confirmed for example that
stack_top_variable and message_p are allocated next to each other on
the stack in my build, with the i variable not between them in memory.
- Re: GC and stack marking, (continued)
Re: GC and stack marking, Barry OReilly, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Barry OReilly, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Daniel Colascione, 2014/05/21
- Re: GC and stack marking, David Kastrup, 2014/05/22
- Re: GC and stack marking, Stefan Monnier, 2014/05/22
- Re: GC and stack marking, Eli Zaretskii, 2014/05/22
Re: GC and stack marking,
Barry OReilly <=
Re: GC and stack marking, Eli Zaretskii, 2014/05/22