Missing ResourceMark in TraceStream::print_val()

Staffan Larsen staffan.larsen at oracle.com
Tue Apr 15 10:57:53 UTC 2014


The comment in code to says that the necessary ResourceMark is in the generated code:

  // Caller is machine generated code located in traceEventClasses.hpp
  // Event<TraceId>::writeEvent() (pseudocode) contains the
  // necessary ResourceMark for the resource allocations below.
  // See traceEventClasses.xsl for details.
  void print_val(const char* label, const Klass* const val) {


/Staffan

On 15 apr 2014, at 11:54, 梅路峣(云达) <yunda.mly at taobao.com> wrote:

> Hi all,
> 
> In TraceStream::print_val(const char* label, const Klass* const val) and TraceStream::print_val(const char* label, const Method* const val), Symbol::as_C_string() and Method::name_and_sig_as_C_string() are called in line 93 and 106 of traceStream.hpp, respectively. Since they both use NEW_RESOURCE_ARRAY to allocate memory, I think ResourceMark should be used. Please see the patch below:
> 
> diff -r 4dedef5e51ed src/share/vm/trace/traceStream.hpp
> --- a/src/share/vm/trace/traceStream.hpp	Fri Apr 11 11:23:30 2014 -0700
> +++ b/src/share/vm/trace/traceStream.hpp	Tue Apr 15 15:50:31 2014 +0800
> @@ -86,6 +86,7 @@
>    // necessary ResourceMark for the resource allocations below.
>    // See traceEventClasses.xsl for details.
>    void print_val(const char* label, const Klass* const val) {
> +    ResourceMark rm;
>      const char* description = "NULL";
>      if (val != NULL) {
>        Symbol* name = val->name();
> @@ -101,6 +102,7 @@
>    // necessary ResourceMark for the resource allocations below.
>    // See traceEventClasses.xsl for details.
>    void print_val(const char* label, const Method* const val) {
> +    ResourceMark rm;
>      const char* description = "NULL";
>      if (val != NULL) {
>        description = val->name_and_sig_as_C_string();
> 
> 
> 
> Regards,
> Yunda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140415/9f213ac6/attachment.html>


More information about the serviceability-dev mailing list