RFR 8227103: Shenandoah: Refactor ShenandoahNMethod in preparation of concurrent nmethod iteration

[Zhengyu Gu]

On 8/2/19 6:42 AM, Aleksey Shipilev wrote:
> On 7/23/19 5:40 PM, Zhengyu Gu wrote:
>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8227103/webrev.01/
> Getting back to this! The refactoring generally looks good. Some minor things:
> 
> *) I wonder if we actually need to store _nmethod_table_state in ShenandoahCodeRootsIterator? It
> looks as if that state is actually table-internal, and should be moved there? Actually, I don't see
> the need for ShenandoahNMethodTableState, we can just as ShenandoahNMethodTable to iterate itself?

Right. It was influenced by following up changes too much.

Updated: http://cr.openjdk.java.net/~zgu/JDK-8227103/webrev.02/


> 
> *) It looks like ShenandoahNMethodTable::log_(un)register_nmethod can be replaced with just
> one-liners like: log_debug(gc, nmethod)(...), and inlined into their only uses?
> 

IIRC, the one-line version constructs parameters before checking if 
logging is enabled, so have to pay the penalty even logging is disabled, 
and parameter constructions here are not trivial.

Reran hotspot_gc_shenandoah (fastdebug and release)

Thanks,

-Zhengyu


>