jameskuyper said:
Has anyone suggested otherwise? I assumed that your mention of
"unaligned storage" was referring to copying a pointer into
incorrectly aligned storage (as might happen when packing a struct)
and then restoring it to correctly aligned storage before attempting
to dereference it - has anyone actually suggested attempting to
dereference such a pointer before realigning it? Does it cause any
less of a problem for GC if it is realigned before usage?
if the pointer is misaligned in the first place, it is likely that someone
will try to use it misaligned, otherwise there is not much reason for it to
be misaligned in the first place (apart from the possible buffer-copying
example, which would place the restriction that the buffer "should" be
aligned...).
but, mostly I am concerned with things likely to happen in practice, not as
much with esoteric edge cases...
Well, certainly. Has anyone suggested trying to use an obfuscated
pointer without first restoring the original form? Does it cause any
less of a problem for GC if it is restored to it's original form
before being dereferenced?
yeah, even if restored, obfuscated pointers may be missed by the GC.
if being used, a person would need to use them with non-GC memory...
however, the issue here is that there is no simple or effective algorithm I
am aware of for dealing with this case in a GC, making the point moot.
Well, certainly - such pointers can only be used while the program
that wrote the pointer is still running, and the object that it
originally pointed to has not yet ended it's lifetime. Has anyone
suggested otherwise? Does it cause any less of a problem for GC if it
is only used before the end of that lifetime?
but then why would anyone be writing the pointer to a file?...
it is usually the case that files are used with the intention of persistent
storage, and so, there is not so much reason to write a pointer to a file
and not expect it to remain intact between runs...
It's perfectly feasible to use each of the techniques listed above to
side-step this "requirement", so long as you pay close attention to
the actual requirements for doing so safely.
not necessarily, or at least not in a concurrent GC...
that is, the main app thread and GC thread may be "doing their thing" at the
same time...
(the other case would involve needing to pause all the "managed" threads
prior to running the GC, which has been a temptation at times...).
technically, it is not safe to handle GC'ed memory in any thread not
originally created by the GC (apart from the "main" thread, which is handled
specially, as well as the GC's internal threads, ...).
As long as you're aware that this requirement is entirely an artifact
of your simplification, and has no basis in reality, that's fine.
Otherwise it's like making the simplification "human beings have two
legs", and then using that simplification to justify asserting that
people cease to be human when they lose one or more of their legs.
it has a basis in reality:
performance and implementability of the GC...
using this example and means of arguing:
because some people may lack legs, that means no one should use stairs...
yet one can clearly see that stairs are the accepted means of going up and
down between floors, ... (well, that, elevators, and escalators... where in
the airport I had seen occasional wheelchairs going up and down on the
escalators...).
but, whether to do something funky with pointers is a programmer choice, not
a physical disability...
Human-generated code follows that "rule" too - not because it's
actually a rule, but because reasons justifying violation of that non-
rule are rare.
ok.
Yes. But more importantly, we can also expect that any compiler
claiming to conform to the standard will allow all three of the
techniques mentioned above to work properly, if done in the correct
fashion.
with malloc...
otherwise, it depends on the specifics of the runtime functions used...
My very first message on this subthread described my understanding of
what you were talking about as follows:
If you weren't actually talking about restoring the original pointer
a) in correctly aligned memory
b) with it's original object representation
c) during the lifetime of the pointed-at object
then you should have commented on my description with a more detailed
explanation of what you were actually talking about. But I find it
hard to see how idiotic code attempting to use pointers that haven't
been properly restored has anything to do with the context in which
you made that statement.
I think context has been lost along the way.
I would have to look back to see whether the context was GC'ed memory or
malloc'ed memory...
(my thinking is that the pointer may disappear or reappear, but this does
not necessarily related to the pointed to memory, rather to the
representation of the pointer / its memory address...).
but, oh well, whatever...
