On Fri, Aug 7, 2020 at 1:34 PM Predrag Radovic <[email protected]> wrote:
>
>
> Keep in mind that every now and then, the RAM layout of the AtomSpace
> changes. This may be due to bug fixes, new features, or simply that a new
> compiler decided to pack things differently (e.g. c++ std library changes,
> e.g. for strings, vectors, mutexes, etc).
>
>
> Of course. If compiler changes data layout, export/import (backup/restore)
> mentioned in my previous email will have to be performed. I hope these
> compiler changes are not happening frequently.
>
A new C++ standard comes out every few years. Both gcc and llvm issue new
compilers every year or two, which different distros pick up at different
times. This also holds for Apple. So there are 3-5 major distros to think
about, if we include raspberry pi in the mix. Memory layout also depends on
libc which changes maybe only every 2-4 years. The most recent change
removes several dozen deprecated features/functions, including syscalls,
and is moving pthread_create to the main library. So the linkage is
changing. Also, linkage depends on kernel headers. All syscalls go through
kernel headers. It's relatively unlikely that kernel header changes will
alter the atomspace mem layout, unless, of course, intel has another
snooping bug which is fixed by some wacky change to the alignment of some
struct somewhere.
Unlike ABI's for compiled binaries, there is no ABI for RAM layout. You
must assume a different layout any time you install, update, upgrade
anything. So the memory-mapped RAM thing is NOT suitable for long-term
storage; it's good only on stable systems that are not being churned.
Oh, and then there's ASR -- address space randomization -- used to prevent
viruses/worms from grabbing hold. I don't know how this might affect a file
that has been closed and re-opened.
As I write this, it seems to me that the memory-mapped atomspace might just
be a re-invention of swapping. Perhaps you can get the same effect by
telling the kernel to use a special swapfile for just this one process but
it now seems to me that is effectively what you describe...
And there is a weird way to do that: set the core-file size to "unlimited",
then force a core-dump, and then every time you restart, you are using the
RAM layout in the core-dump...
Hmmm...
--linas
--
Verbogeny is one of the pleasurettes of a creatific thinkerizer.
--Peter da Silva
--
You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/CAHrUA34fg1RxF4hmL5MvmjCgfMi9J7%2BwuG%2BFiu6%2B9ySWnBEP6Q%40mail.gmail.com.
