Re: [ANN] mathx for Lua 5.3

[William Ahern <william@...>]

On Thu, May 07, 2015 at 12:54:23PM -0700, Tim Hill wrote:
> 
> > On May 6, 2015, at 12:02 PM, William Ahern <william@25thandClement.com> wrote:
> > 
> > Most people consider Windows DLLs to be shared libraries, but they don't use
> > position independent code in that there's no GOT table or similar mechanism.
> > Rather, the linker literally has to hack the binary and the DLL in order to
> > change function addresses if there's a conflict. Sometimes it can't succeed.
> > This is one of the reasons for so-called DLL hell. It also means that
> > Windows often uses more memory than other systems because two processes
> > sharing the same DLL can't share the virtual memory pages for that DLL if
> > one of the processes had to rewrite the DLL at load time.
> 
> it???s a bit unfair to call fixups a ???hack???

Oops. I didn't mean it pejoratively. It was just the first word that came to
mind. You're right in that it's not inherently broken.

> and in fact they never fail (DLL hell has another cause entirely).

I was thinking of failures like "Illegal System DLL Relocation", such as

	https://support.microsoft.com/en-us/kb/935448

but those are unique in that the DLLs were intentionally compiled to require
a specific base address.

I also thought the problem with mixing MVSCRT.dll versions[1] was related, but
I was wrong.

[1] See https://msdn.microsoft.com/en-us/library/ms235460.aspx. They're
working to change this. See
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx

> Fixing up object code at load time is no different to the routine
> relocations linkers routinely do when merging compiled object files (for
> example, when loading static object code libraries).
> 
> To be fair to Microsoft, the standard set of Windows system DLLs always
> had carefully predefined load addresses so that collisions were rare (and
> when they did occur they could be statically relocated at load time),
> which typically meant they COULD be shared across processes via shared
> copy-on-write pages. It was only when random-address loading was added as
> an anti-virus measure that pic became desirable/necessary.
> 
> And it should be remembered that pic has runtime overhead (slower
> execution) as the compiler must generate extra code in many cases.

Processors rely on deep pipelines and prefetching so much that the cost has
shrunk.

Plus, if a library isn't in shared memory, it's less likely to be in L1/2/3
cache after a context switch. So in addition to wasting memory, it could
also be slower even if none of the code is paged out. But I have no idea if
that is significant in real-world software. Probably not. (OTOH, Intel, AMD,
and ARM have gone to considerable lengths to preserve CPU caches across
context switches. And all three recently added tagged TLB tables, so virtual
address remapping is minimized.)