RFR[13]: 8227277: HeapInspection::find_instances_at_safepoint walks dead objects
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Mon Jul 8 15:11:42 UTC 2019
On 7/5/19 11:26 AM, Erik Österlund wrote:
>
>
> On 2019-07-05 13:35, David Holmes wrote:
>> 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. :)
>
> Thanks!
>
>> Are there any valid uses for the (unsafe) object_iterate?
>
> Well... valid might be an overstatement, but I think it probably won't
> crash if you don't pointer chase through dead references in dead
> objects. We simply can't do that.
This change looks good, but I have to echo David's question. It looks
like we have the same thing in jvmtiTagMap, with some out of date comments.
hare/prims/jvmtiTagMap.cpp: // consider using safe_object_iterate()
which avoids perm gen
share/prims/jvmtiTagMap.cpp: Universe::heap()->object_iterate(_blk);
share/prims/jvmtiTagMap.cpp: Universe::heap()->object_iterate(&blk);
Should we eliminate all uses of Universe::heap() version of
object_iterate? It looks like the GCs call it, and it's probably safe
in those places, so should not be a virtual function for each GC?
Thanks,
Coleen
>
> Thanks,
> /Erik
>
>> Cheers,
>> David
>>
>>> Thanks,
>>> /Erik
>
More information about the hotspot-dev
mailing list