[ruby-core:97574] Re: [Ruby master Bug#16694] JIT vs hardened GCC with PCH

On 03/21/2020 03:13 PM, [e-mail] wrote:
> Issue #16694 has been updated by k0kubun (Takashi Kokubun).
>
>
>> But how about performance? It has to lead to slower compilation (at least the second time). I worry about usability of JIT with disabled PCH. At least 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 chances for JIT. Thus I think the main use case is a long-running server process, 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.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 behaviour has the same security risk. For an attacker it would be easier to corrupt 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 intended is a security risk, I agree with the point for CRuby's usage if it's about a risk caused by modifying PCH. An attacker who has permission to modify Ruby's prefix should be able to modify Ruby's standard libraries too, without 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 enabling page randomization.
Simply GCC PH implementation is basically memory dump and to reuse it 
you need GCC to have the same virtual start address.GCC PH 
implementation is too old (I remember people started working on this 
more 20 years ago).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.GCC/Clang LTO approach uses also a real IR streaming so it 
works with ASLR.Coming C++ modules (GCC and Clang) also use real IR 
streaming.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 investigated before adopting this approach.
I never investigated this.So this is just an idea.Also LTO (at least 
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. People recently tried to use LTO for whole linux distribution 
and found a lot of programs with such undefined behaviour.


Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>