104   // Used in support of ReduceInitialCardMarks; only consulted if COMPILER2

   105   // or INCLUDE_JVMCI is being used

   106   bool _defer_initial_card_mark;

   107 

   131 

   132   // Do common initializations that must follow instance construction,

   133   // for example, those needing virtual calls.

   134   // This code could perhaps be moved into initialize() but would

   135   // be slightly more awkward because we want the latter to be a

   136   // pure virtual.

   137   void pre_initialize();

   411   // Can a compiler initialize a new object without store barriers?

   412   // This permission only extends from the creation of a new object

   413   // via a TLAB up to the first subsequent safepoint. If such permission

   414   // is granted for this heap type, the compiler promises to call

   415   // defer_store_barrier() below on any slow path allocation of

   416   // a new object for which such initializing store barriers will

   417   // have been elided.

   418   virtual bool can_elide_tlab_store_barriers() const = 0;

   419 

   420   // If a compiler is eliding store barriers for TLAB-allocated objects,

   421   // there is probably a corresponding slow path which can produce

   422   // an object allocated anywhere.  The compiler's runtime support

   423   // promises to call this function on such a slow-path-allocated

   424   // object before performing initializations that have elided

   425   // store barriers. Returns new_obj, or maybe a safer copy thereof.

   426   virtual oop new_store_pre_barrier(JavaThread* thread, oop new_obj);

   427 

   428   // Answers whether an initializing store to a new object currently

   429   // allocated at the given address doesn't need a store

   430   // barrier. Returns "true" if it doesn't need an initializing

   431   // store barrier; answers "false" if it does.

   432   virtual bool can_elide_initializing_store_barrier(oop new_obj) = 0;

   433 

   434   // If a compiler is eliding store barriers for TLAB-allocated objects,

   435   // we will be informed of a slow-path allocation by a call

   436   // to new_store_pre_barrier() above. Such a call precedes the

   437   // initialization of the object itself, and no post-store-barriers will

   438   // be issued. Some heap types require that the barrier strictly follows

   439   // the initializing stores. (This is currently implemented by deferring the

   440   // barrier until the next slow-path allocation or gc-related safepoint.)

   441   // This interface answers whether a particular heap type needs the card

   442   // mark to be thus strictly sequenced after the stores.

   443   virtual bool card_mark_must_follow_store() const = 0;

   444 

   445   // If the CollectedHeap was asked to defer a store barrier above,

   446   // this informs it to flush such a deferred store barrier to the

   447   // remembered set.

   448   virtual void flush_deferred_store_barrier(JavaThread* thread);

   449