Request for Review(S): ResourceMark nesting problem in stringStream

[David Holmes]

Hi Yang,

That looks okay to me.

Was the 1024 buffer size determined empirically?

David

On 14/02/2012 8:07 PM, Wang, Yang wrote:
> Hello David,
>     DEBUG deleted, and you are right, it is not necessary to dynamically allocate stringStream.
>     The new webrev is located in:
> http://www.sapjvm.com/yw/webrevs/7143807/
>
> Thanks,
> Yang
>
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 9. Februar 2012 04:03
> To: Paul Hohensee
> Cc: Wang, Yang; 'hotspot-compiler-dev at openjdk.java.net'; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: Request for Review(S): ResourceMark nesting problem in stringStream
>
> General comment: don't use a space between # and ifdef/endif
>
> src/share/vm/utilities/ostream.cpp:
>
> + # ifdef DEBUG
> +   assert( buffer_fixed         // fixed buffer can be nested, as
> overflow is silently truncated
> +           || buffer_resource_area_nesting ==
> Thread::current()->resource_area()->_nesting,
> +       "writing to stringStream with nested ResourceMark");
> + # endif
>
> The ifdef DEBUG is unncessary. The assert will evaporate in a non-debug
> build.
>
> ---
>
> share/vm/prims/methodHandleWalk.cpp
>
> I don't understand why we now have to dynamically allocate the stringStream?
>
> David
> -----
>
> On 9/02/2012 1:36 AM, Paul Hohensee wrote:
>> I've filed
>>
>> 7143807: ResourceMark nesting problem in stringStream
>>
>> for this and assigned it to the runtime group since it's not actually a
>> compiler bug.
>>
>> Paul
>>
>> On 2/7/12 9:28 AM, Wang, Yang wrote:
>>>
>>> Hi folks,
>>>
>>> We found that Hotspot allows ResourceMark nesting for stringStream
>>> object. This can corrupt memory when the stringStream object is
>>> expanded under the second level ResourceMark.
>>>
>>> Detailed descriptions could be found in webrev
>>> http://www.sapjvm.com/yw/webrevs/ResourceMark_nesting/
>>>
>>> I don't have a bugID yet. Please kindly open one bug for this issue.
>>>
>>> Thanks,
>>>
>>> Yang
>>>
>>> *Yang Wang
>>> *Software Engineer
>>>
>>> TIP Core AS&VM Technology (AG)*
>>> *SAP JVM JIT Compiler//
>>>
>>> *SAP AG**
>>> *Dietmar-Hopp-Allee 16
>>> 69190 Walldorf, Germany**
>>>
>>> T +49 6227 7-50320*
>>> *F +49 6227 78-48541*
>>> *Email : yang02.wang at sap.com<mailto:yang02.wang at sap.com>*
>>> *www.sap.com
>>>
>>> *
>>> *Pflichtangaben/Mandatory Disclosure Statements:
>>> http://www.sap.com/company/legal/impressum.epx*
>>>
>>> *Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
>>> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
>>> irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
>>> eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich
>>> untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
>>> empfangene E-Mail. Vielen Dank. *
>>>
>>> *This e-mail may contain trade secrets or privileged, undisclosed, or
>>> otherwise confidential information. If you have received this e-mail
>>> in error, you are hereby notified that any review, copying, or
>>> distribution of it is strictly prohibited. Please inform us
>>> immediately and destroy the original transmittal. Thank you for your
>>> cooperation.
>>>