Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
tagged pointers
8 views
Skip to first unread message
bulk88
Nov 14, 2012, 8:09:04 PM11/14/12
to perl5-...@perl.org
allowed or forbidden?
Craig A. Berry
Nov 16, 2012, 2:11:19 PM11/16/12
to bulk88, perl5-...@perl.org
On Wed, Nov 14, 2012 at 7:09 PM, bulk88 <bul...@hotmail.com> wrote:
> allowed or forbidden?
Short answer: as with all major, invasive changes to how the
interpreter is implemented, it's forbidden until you make it work and
show that it's useful :-).
Somewhat longer answer:
I don't recall ever seeing them discussed here (though I don't read
everything and certainly don't recall everything). In fact, I didn't
know what they were until your post prompted me to read up on them. I
found a post on Apple's use of them in Lion [1] and a Microsoft
research article [2] more helpful than most of the other easily
accessible discussions.
I have to say it sounds rather ghastly because it would mean owning a
support matrix whose dimensions are pointer size, alignment
granularity, endianness, and possibly implementation-defined uses of
low bits in a pointer. Where "implementation" includes the virtual
memory implementation, the C compiler, and the tools that do tracing,
debugging, leak-finding, etc., any of which might hiccup on a pointer
that's made intentionally invalid in order to hide a few bits of data
in it. And all tagged pointers must never, ever be dereferenced
without being de-tagged first.
If it can be done portably at all, it sounds like you could only rely
on getting about 2 bits of data in a 32-bit pointer (correct me if
I've misunderstood that). Or if you know the page size and can
determine that the first page of memory can never be referenced by a
valid address and are willing to risk running afoul of anything that
checks for such invalid pointers you might get a few bits more. Is
that enough to make it worthwhile?
If it's not done portably, and is only done when using, say, 64-bit
pointers on a platform that guarantees octaword alignment for
everything created by malloc(), then we'd have to provide a fallback
implementation for everything else. Which increases code complexity.
I *think* this is what JavaScript does, but I haven't researched it
thoroughly enough to be sure. My impression is that JavaScript
development has a lot more commercial support and is less portable
than Perl, so a different cost-to-benefit ratio might be acceptable
for them.
Having said all that, I'm not sure it's worse than other things we
already do that depend on implementation details we aren't supposed to
rely on (buffer snooping comes to mind). But I doubt it's worth the
risk. I would be delighted to be proven wrong; i.e., if you can
demonstrate that tagged pointers in the Perl core would be simple and
beautiful and portable and have a notable performance benefit, that
would be awesome.
[1] http://objectivistc.tumblr.com/post/7872364181/tagged-pointers-and-fast-pathed-cfnumber-integers-in
[2] http://research.microsoft.com/pubs/67969/ptr-tagging.pdf
> allowed or forbidden?
Short answer: as with all major, invasive changes to how the
interpreter is implemented, it's forbidden until you make it work and
show that it's useful :-).
Somewhat longer answer:
I don't recall ever seeing them discussed here (though I don't read
everything and certainly don't recall everything). In fact, I didn't
know what they were until your post prompted me to read up on them. I
found a post on Apple's use of them in Lion [1] and a Microsoft
research article [2] more helpful than most of the other easily
accessible discussions.
I have to say it sounds rather ghastly because it would mean owning a
support matrix whose dimensions are pointer size, alignment
granularity, endianness, and possibly implementation-defined uses of
low bits in a pointer. Where "implementation" includes the virtual
memory implementation, the C compiler, and the tools that do tracing,
debugging, leak-finding, etc., any of which might hiccup on a pointer
that's made intentionally invalid in order to hide a few bits of data
in it. And all tagged pointers must never, ever be dereferenced
without being de-tagged first.
If it can be done portably at all, it sounds like you could only rely
on getting about 2 bits of data in a 32-bit pointer (correct me if
I've misunderstood that). Or if you know the page size and can
determine that the first page of memory can never be referenced by a
valid address and are willing to risk running afoul of anything that
checks for such invalid pointers you might get a few bits more. Is
that enough to make it worthwhile?
If it's not done portably, and is only done when using, say, 64-bit
pointers on a platform that guarantees octaword alignment for
everything created by malloc(), then we'd have to provide a fallback
implementation for everything else. Which increases code complexity.
I *think* this is what JavaScript does, but I haven't researched it
thoroughly enough to be sure. My impression is that JavaScript
development has a lot more commercial support and is less portable
than Perl, so a different cost-to-benefit ratio might be acceptable
for them.
Having said all that, I'm not sure it's worse than other things we
already do that depend on implementation details we aren't supposed to
rely on (buffer snooping comes to mind). But I doubt it's worth the
risk. I would be delighted to be proven wrong; i.e., if you can
demonstrate that tagged pointers in the Perl core would be simple and
beautiful and portable and have a notable performance benefit, that
would be awesome.
[1] http://objectivistc.tumblr.com/post/7872364181/tagged-pointers-and-fast-pathed-cfnumber-integers-in
[2] http://research.microsoft.com/pubs/67969/ptr-tagging.pdf
0 new messages