RFR: 8270947: AArch64: C1: use zero_words to initialize all objects [v5]

[Andrew Haley]

On 7/30/21 4:55 PM, Andrew Dinn wrote:
> My initial reaction to that extra last commit was that anything other than a compiler thread calling MacroAssembler::zero_words implies "Something is rotten in the state of Danmark" and the only end game is a stage strewn with corpses. Of course, zero_words gets called from the stub generator. However, I guess the stub complete check avoids any problems there.
> 
> Were you thinking of some other potential use for it? e.g. lazy intrinsics?
> 
> Anyway, the check certainly does no harm so it is all still good.

I *think* it's probably unnecessary. However, we do lazily generate IC
buffers from Java code, and we use the assembler to do that. So in general
it is not against any rules to use the MacroAssembler from non-compiler
threads.

It is certainly the case that you can't call ciEnv::current() unless
you're on a compiler thread without risking Severe Badness, because
current() blindly does this:

  static CompilerThread* current() {
=>  return CompilerThread::cast(JavaThread::current());
  }
  static CompilerThread* cast(Thread* t) {
    assert(t->is_Compiler_thread(), "incorrect cast to CompilerThread");
    return static_cast<CompilerThread*>(t);
  }

And therefore ciEnv::current()->task() is Undefined Behaviour if not on a
CompilerThread.

(This is pretty awful, and I should submit a patch to perhaps add
ciEnv::current_orNull(). But not in this patch.)

So it's fairly uncontroversial, I would have thought, to guard
all calls to ciEnv::current() from MacroAssembler with is_Compiler_thread().

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671