[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFR: 8265322: C2: Simplify control inputs for BarrierSetC2::obj_allocate
From:       Yi Yang <yyang () openjdk ! java ! net>
Date:       2021-04-29 11:48:56
Message-ID: SNXXXqrLw0a8ULE9U6V5mgyNJWbngM7W6Y__myHyGLQ=.7c80f9ff-da8d-42b7-89c5-92052e70bea9 () github ! com
[Download RAW message or body]

On Mon, 19 Apr 2021 17:26:14 GMT, Vladimir Kozlov <kvn@openjdk.org> wrote:

> > While just using BarrierSetC2::obj_allocate in \
> > https://github.com/openjdk/valhalla/pull/385, I noticed the control input `ctrl` \
> > for obj_allocate is not so much necessary. This PR simplifies control inputs for \
> > BarrierSetC2::obj_allocate. In most cases, it doesn't change anything since \
> > `toobig_false` is equivalent to `ctrl`. In other cases, `toobig_false` is created \
> > for Unsafe.allocateInstance while instance size is not statically known, `ctrl` \
> > would become control input of IfNode whose projects are `toobig_false` and \
> > `toobig_true`, old eden_end and old_eden_top can simply accept `toobig_false` as \
> > their control input rather than `ctrl`.
> 
> > > From compiler code POV the fix is reasonable and correct.
> > Do you think it's reasonable to move PhaseMacroExpand::set_eden_pointers to \
> > BarrierSetC2? It seems that that's GC knowledge area about how to set \
> > eden_top/eden_end w or w/o turning UseTLAB.
> 
> It is up to GC group but it is common code for all GCs. As I understand \
> BarrierSetC2 is used for GC variations code.

Thanks @vnkozlov and @neliasso for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3529


[prev in list] [next in list] [prev in thread] [next in thread]