[11u] RFR 8249192: MonitorInfo stores raw oops across safepoints

[Lindenmaier, Goetz]

Hi Aleksey,

The downport looks good. 

One could fear that the HandleMark in deoptimization.cpp 
is forgotten in case of a downport of 8226705. But a downport 
of this change is  most unlikely I guess.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On Behalf
> Of Aleksey Shipilev
> Sent: Tuesday, September 1, 2020 11:47 AM
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR 8249192: MonitorInfo stores raw oops across safepoints
> 
> Original bug:
>    https://bugs.openjdk.java.net/browse/JDK-8249192
>    https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d
> 
> The bulk of the patch applies exactly, but some hunks need adjustments.
> 
>   *) In jvmtiEnvBase.cpp, the hunk removing "ResourceMark
> rm(current_thread)" cannot be applied,
> because "current_thread" is added with JDK-8247729:
>    https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82
> 
>   ...I just removed the ResourceMark by hand.
> 
>   *) In deoptimization.cpp, there is no eliminate_locks yet -- it is refactored
> out of "if
> (EliminateLocks)" branch later with JDK-8226705:
>    https://hg.openjdk.java.net/jdk/jdk/rev/408c445d04e8#l21.162
>    https://hg.openjdk.java.net/jdk/jdk/rev/408c445d04e8#l21.59
> 
>   ...so I put the HandleMark in the old place.
> 
> Note it has a follow-up JDK-8251118, which needs to be backported too.
> Since the whole thing has a
> non-zero risk, it targets 11.0.10.
> 
> 11u webrev:
>    https://cr.openjdk.java.net/~shade/8249192/webrev.11u.01/
> 
> Testing: tier{1,2,3} with and without Shenandoah [which seems to find some
> of these bugs]
> 
> --
> Thanks,
> -Aleksey