RFR[13]: 8227277: HeapInspection::find_instances_at_safepoint walks dead objects

David Holmes david.holmes at oracle.com
Fri Jul 5 11:35:59 UTC 2019


Hi Erik,

On 5/07/2019 8:19 pm, Erik Österlund wrote:
> Hi,
> 
> In the HeapInspection::find_instances_at_safepoint function, the unsafe 
> heap iteration API (which also walks dead objects) is used to find 
> objects that are instance of a class, used for concurrent lock dumping 
> where we find dead 
> java.util.concurrent.locks.AbstractOwnableSynchronizer objects and 
> pointer chase to its possibly dead owner threadObj. There is a comment 
> saying that if this starts crashing because we use CMS, we should 
> probably change to use the safe_object_iterate() API instead, which does 
> not include dead objects.
> 
> Arguably, whether CMS is observed to crash or not, we really should not 
> be walking over dead objects and exposing them anyway. It's not safe... 
> and it will crash sooner or later.
> 
> For example, CMS yields to safepoints (including young GCs) while 
> sweeping. This means that both the AbstractOwnableSynchronizer and its 
> owner thread might have died, but while sweeping, we could yield for a 
> young GC that promotes objects overriding the memory of the dead thread 
> object with random primitives, but not yet freeing the dead 
> AbstractOwnableSynchronizer. A subsequent dumping operation could use 
> the heap walker to find the dead AbstractOwnableSynchronizer, and 
> pointer chase into its dead owner thread, which by now has been freed 
> and had its memory clobbered with primitive data.
> 
> This will all eventually end up in a glorious crash. So we shouldn't do 
> this.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8227277
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8227277/webrev.00/

That seems eminently reasonable. :)

Are there any valid uses for the (unsafe) object_iterate?

Cheers,
David

> Thanks,
> /Erik


More information about the hotspot-dev mailing list