An inconsistency in the handling of the _wb_conc_mark GCCause by G1 was introduced by JDK-8232588. We get into try_collect_concurrently because is_user_requested_concurrent_full_gc is true for it, and the policy handling by decide_on_conc_mark_initiation similarly uses that function to decide whether concurrent marking should be forced (skipping mixed gc's and the like).

But then try_collect_concurrently uses GCCause::is_user_requested_gc to select how to handle the result of the VMOp, and that function returns false for _wb_conc_mark.

This treatment of _wb_conc_mark as a non-user-request for VMOp result handling can result in the request unexpectedly not actually starting a concurrent collection cycle.

It may be that try_collect_concurrently should be consistently using is_user_requested_concurrent_full_gc. However, it may also be that GCCause::is_user_requested_gc should be true for _wb_conc_mark.