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