[9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation

Vladimir Kozlov vladimir.kozlov at oracle.com
Sat Oct 11 03:41:32 UTC 2014


Next method puts C2's EA to its knees:



It shows that current EA connection graph build code is very inefficient 
when a graph has a lot of connections (edges).

With inlining the BTreeEntry::put() method has about 100 allocations 
from which about 80 are arrays allocations. Most of them are object 
arrays which are generated by Arrays.copyOf(). After number of edges in 
EA Connection Graph reaches about 50000 it takes more then 1 sec to find 
all nodes which reference an allocation.

Current EA code has bailout by timeout from graph building code. But the 
timeout (30 sec for product VM) is checked only after all object nodes 
are processed. So it may take > 2 mins before EA is aborted:

<phase name='connectionGraph' nodes='18787' live='10038' stamp='4.417'>
<connectionGraph_bailout reason='reached time limit'/>
<phase_done name='connectionGraph' nodes='18787' live='10038' 

Also ConnectionGraph::add_java_object_edges() method does not check the 
presence of a node when it adds new one to the worklist (in 
add_to_worklist() method). Which leads to hundreds MB of used by EA 
memory when BTreeEntry::put() is processed.

To address issues new timeout checks were added.
New _pidx index field is added to graph's nodes and VectorSet is used to 
reduce size of worklist in add_java_object_edges() method.

Escaping node CreateEx is mapped phantom_obj to reduce number of process 
objects in connection graph. We do the same for other escaping objects.

Tested with graphhopper server application:

<phase name='connectionGraph' nodes='18787' live='10038' stamp='6.829'>
<connectionGraph_bailout reason='reached time limit'/>
<phase_done name='connectionGraph' nodes='18787' live='10038' 


More information about the hotspot-compiler-dev mailing list