Re: [Tinycc-devel] enforced immutability - proposed research project

[arnold]

+ Do the work in a separate branch, not on mob which people use for production

"Christian Jullien" <eligis@orange.fr> wrote:

> + project duration
>
> -----Original Message-----
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange.fr@nongnu.org] 
> On Behalf Of Christian Jullien
> Sent: Tuesday, January 19, 2021 06:46
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] enforced immutability - proposed research project
>
> Gentlemen,
> I'm happy to see you have a lot of ideas. Here is what I propose:
> - take time to think about the approach you want to implement this feature, 
> ask advices from maintainers if you like.
> - move implementation discussion to another list
> - THEN propose a research subject with:
>   * estimated compilation speed impact (goal/non goal)
>   * estimated execution speed impact (goal/non goal)
>   * availability/portability on OS/cpu/compiler (IMHO at least mainline 
> architectures, I would say Linux/[x64, aarch64, riscv 64], Windows x64 and 
> another un*x like *BSD) - Okay, riscv is not yet mainline but hope it will 
> soon.
>   * user interface (set using configure option, set using a compiler option, 
> new __attribute__ etc...)
>   * impact on current source code (mostly implemented in a new file, 
> dissimilated in source code with #if/#endif, with macro, ...)
>   * list gold ports (i.e. ports tested before any commits) and silver ports 
> (i.e. ports that also probably work after commits).
>   * nominate a coordinator for this project
> - wait approval from maintainers.
>
> Sounds reasonable?
>
> Christian
>
> -----Original Message-----
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange.fr@nongnu.org] 
> On Behalf Of Elijah Stone
> Sent: Tuesday, January 19, 2021 02:44
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] enforced immutability - proposed research project
>
> On Tue, 19 Jan 2021, Bruno Haible wrote:
>
> > MAP_FIXED is a portability nightmare nowadays, where most OSes implement 
> > address space randomization and put the shared libraries at arbitrary 
> > and random locations in the address space. You better stay away from it.
> >
> > The implementation I pointed to therefore doesn't use MAP_FIXED, just 
> > plain MAP_SHARED.
>
> The problem is, without a fixed offset between the mutable and immutable 
> spaces, certain desirable semantics become harder to implement.  For 
> example, we want mutable and immutable references to the same object to 
> compare equal.
>
> One potential solution is to rely on overcommit.  Map a giant memory 
> region, and then remap the second portion (using MAP_FIXED) to alias the 
> first half.  (Using MAP_FIXED to overwrite existing address space mappings 
> _is_ a supported usage.)
>
>   -E
>
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel