On 03/21/2020 03:13 PM, takashikkbn / gmail.com wrote:
> Issue #16694 has been updated by k0kubun (Takashi Kokubun).
>
>
>> But how about performance? It has to lead to slower compilation (at leas=
t the second time). I worry about usability of JIT with disabled PCH. At le=
ast it would be cool if we can document somewhere the impact
> First of all, I don't think JIT is useful for scripting purposes as most =
of the code may be called only a few times which leaves few optimization ch=
ances for JIT. Thus I think the main use case is a long-running server proc=
ess, and performance of compiled code is more important than time taken for=
 compilation which should be way shorter than the process's uptime.
> As you said, the usability depends on how it could be slow. I agree that =
the impact should be documented.
Yes. You are probably right, Takashi.=A0 The major Ruby applications like =

RoR are long running programs and you have much more experience with JIT =

behaviour on real Ruby applications.

I just remember that for some small benchmarks, e.g. from programming =

language shootout, compilation speed was important. Unfortunately, =

people pay a lot of attentions to such benchmarks because it is easier =

to run them.

You are right that it would be nice to know the impact of not using PH.
>> Any program creating and reading a file which somehow affects program be=
haviour has the same security risk. For an attacker it would be easier to c=
orrupt some ruby source (or byte) code file loaded during CRuby work
> While I didn't talk about it as I was not sure what part of PCH Vit inten=
ded is a security risk, I agree with the point for CRuby's usage if it's ab=
out a risk caused by modifying PCH. An attacker who has permission to modif=
y Ruby's prefix should be able to modify Ruby's standard libraries too, wit=
hout waiting for JIT-ing it.
Well, security people can be paranoid and sometimes not looking at the =

whole picture. For me, because of recent security hardware =

vulnerabilities like possibility of reading other process memory, RAM =

seems less protected than files.
>> Unfortunately PCH for PIE GCC can not work with page randominazation.
>> I don't see that somebody in GCC community will re-implement PCH in the =
same way as it is done in Clang.
>> * use only clang for such environments
> Good to know that Clang can be used as a workaround for an environment en=
abling page randomization.
Simply GCC PH implementation is basically memory dump and to reuse it =

you need GCC to have the same virtual start address.=A0 GCC PH =

implementation is too old (I remember people started working on this =

more 20 years ago).=A0 So there is small chance that somebody will =

re-implement it.

Clang approach is real AST streaming it does not depend on Clang start =

address.=A0 GCC/Clang LTO approach uses also a real IR streaming so it =

works with ASLR.=A0 Coming C++ modules (GCC and Clang) also use real IR =

streaming.=A0 So no danger here too.
>> * use one more approach based on non-fat LTO object file generated from =
the header as LTO works for GCC (and Clang) when page randomization (ASLR) =
is used.
> Interesting idea. And yes, the effectiveness of inlining should be invest=
igated before adopting this approach.
I never investigated this.=A0 So this is just an idea.=A0 Also LTO (at leas=
t =

for GCC) is still pretty rarely used feature and might be a problem when =

people use undefined behavior (from C standard point of view) in their =

program.=A0=A0 People recently tried to use LTO for whole linux distributio=
n =

and found a lot of programs with such undefined behaviour.


Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>