RFR(S): 8188151: "assert(entry_for(catch_pco, handler_bcis->at(i), scope_depth)->pco() == handler_pcos->at(i))" failure with C1

dean.long at oracle.com dean.long at oracle.com
Wed Oct 4 01:18:05 UTC 2017


If handler->scope_count() > prev_scope, then can we skip the find 
because no duplicate is possible?

dl


On 10/2/17 2:40 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8188151/webrev.00/
>
> When Compilation::generate_exception_handler_table() walks the exception
> handler information to populate the exception handler table, it has some
> logic that removes duplicate handlers for one particular throwing pc and
> it is wrong AFAICT.
>
> That code iterates over already processed (handler_bci, scope_count,
> entry_pco) triples stored in GrowableArrays bcis, scope_depths, pcos and
> looks for entries for which handler_bci, scope_count are identical to
> the current one. It does that by looking for an entry with same
> handler_bci in the bcis array and then checks whether scope_count
> matches too. The list of triples could be something like:
>
> 1: (13, 0, ..)
> 2: (13, 1, ..)
>
> and the next triple to be process: (13, 1, ..) which is a duplicate of
> 2. That logic looks for a handler with bci 13, finds entry 1 which
> doesn't have scope count 1. And concludes that there no duplicate
> entry. It would need to look at the following entry too. Given scope
> counts are sorted in increasing order, rather that iterate over the list
> of triples from the start, looking for duplicates fromt the end of the
> list fixes that problem.
>
> Roland.



More information about the hotspot-compiler-dev mailing list