RFR(S): 8040920: Uninitialised memory in hotspot/src/share/vm/code/dependencies.cpp
Morris Meyer
morris.meyer at oracle.com
Tue Aug 5 17:28:53 UTC 2014
Vladimir,
Here is a revised version with your suggestions.
I added outer ResourceMarks to
void Dependencies::log_all_dependencies()
and
void Dependencies::write_dependency_to(CompileLog* log,
DepType dept,
GrowableArray<DepArgument>* args,
Klass* witness)
as they are the only callers to
void Dependencies::write_dependency_to(CompileLog* log,
DepType dept,
GrowableArray<ciBaseObject*>* args,
Klass* witness);
which does not have a ResourceMark - so these aren't nested cases.
void Dependencies::DepStream::log_dependency(Klass* witness)
does call
void Dependencies::write_dependency_to(CompileLog* log,
DepType dept,
GrowableArray<DepArgument>* args,
Klass* witness)
which makes it a nested usage of ResourceMark - and I've added a
guarantee() to ensure the outer ResourceMark is not affected by the
inner callee.
void Dependencies::DepStream::print_dependency(Klass* witness, bool
verbose);
has a new GrowableArray usage and I also added an outer ResourceMark
here - and a guarantee() that goes along with the inner ResourceMark
used in the existing code of
void Dependencies::print_dependency(DepType dept,
GrowableArray<DepArgument>* args,
Klass* witness);
This revision has been tested with JPRT.
Thanks for the review!
--morris
JBS - https://bug.openjdk.java.net/browse/JDK-8040920
WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.08
On 7/22/14, 7:05 PM, Vladimir Kozlov wrote:
> how you determined where you should place ResourceMark? You missed one
> in log_dependency().
>
> write_dependency_to() methods are used only by Dependencies so they
> could be private. Then we would guarantee that they are called in
> known places which may have ResourceMark already.
>
> thanks,
> Vladimir
>
> On 7/21/14 3:42 PM, Morris Meyer wrote:
>> Christian and Vladimir,
>>
>> I have incorporated these comments into this latest webrev. It has been
>> put through JPRT west.
>>
>> --mm
>>
>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.07
>> JBS - https://bug.openjdk.java.net/browse/JDK-8040920
>>
>>
>> On 4/30/14, 6:41 PM, Christian Thalinger wrote:
>>> On Apr 30, 2014, at 11:55 AM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com> wrote:
>>>
>>>> On 4/30/14 2:35 PM, Christian Thalinger wrote:
>>>>> On Apr 30, 2014, at 11:26 AM, Vladimir Kozlov
>>>>> <vladimir.kozlov at oracle.com> wrote:
>>>>>
>>>>>> Morris,
>>>>>>
>>>>>> How you verified that you put ResourceMark in all needed places?
>>>>>> That is what I don't like about GrowableArray.
>>>>> He could put a ResourceMark in front of every GrowableArray. That
>>>>> would do it.
>>>> Nested ResourceMark has bad effect on external GrowableArray: if it
>>>> grows after inner ResourceMark that space will be released after
>>>> inner scope ends. You will get memory stomps because of that. You
>>>> need to be sure that external GrowableArray never grows inside inner
>>>> ResourceMark scope.
>>> Ugh. You’re right. Yeah, as I said we don’t need a GrowableArray
>>> here but the regular Array is only for metadata.
>>>
>>>> Vladimir
>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/30/14 11:47 AM, Morris Meyer wrote:
>>>>>>> Vladimir and Christian,
>>>>>>>
>>>>>>> Thank you for the reviews.
>>>>>>>
>>>>>>> This version has your comments incorporated and has been put
>>>>>>> through
>>>>>>> JPRT and passes Parfait cleanly.
>>>>>>>
>>>>>>> --mm
>>>>>>>
>>>>>>> JBS - https://bugs.openjdk.java.net/browse/JDK-8040920
>>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.05
>>>>>>>
>>>>>>>
>>>>>>> On 4/24/14, 2:16 PM, Vladimir Kozlov wrote:
>>>>>>>> Using GrowableArray requires adding ResourceMark otherwise it
>>>>>>>> will be
>>>>>>>> memory leak. Method clear() does not free resources.
>>>>>>>>
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 4/24/14 9:30 AM, Morris Meyer wrote:
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> Could I get a review for this parfait issue? I've refactored
>>>>>>>>> dependencies to use a GrowableArray to protect from
>>>>>>>>> inconsistencies in
>>>>>>>>> passed in argument pairs (int nargs, DepArgument args[])
>>>>>>>>>
>>>>>>>>> Thanks to Christian Thalinger and Vladimir Kozlov for looking at
>>>>>>>>> earlier
>>>>>>>>> versions of this.
>>>>>>>>>
>>>>>>>>> --morris
>>>>>>>>>
>>>>>>>>> JBS - https://bugs.openjdk.java.net/browse/JDK-8040920
>>>>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040920.04
>>>>>>>>>
>>
More information about the hotspot-compiler-dev
mailing list