RFR JDK-8046282: SA update

Poonam Bajaj poonam.bajaj at oracle.com
Mon Jun 9 09:10:50 UTC 2014


Hi Sundar,

Yes, it is possible to do that. e.g.  G1YCType can be defined like this.

public enum G1YCType {
   Normal ("Normal"),
   InitialMark ("Initial Mark"),
   DuringMark ("During Mark"),
   Mixed ("Mixed"),
   G1YCTypeEndSentinel ("Unknown")

   private final String value;

   G1YCType(String val) {
     this.value = val;
   }
   public String value() {
     return value;
   }
}

But, my purpose of having a class and an enum being used in that class 
was to have the similar kind of code structure on the SA side as is 
present on the hotspot side. e.g the above is defined as the following 
on the hotspot side:

030 enum G1YCType {
031   Normal,
032   InitialMark,
033   DuringMark,
034   Mixed,
035   G1YCTypeEndSentinel
036 };
037
038 class G1YCTypeHelper {
039  public:
040   static const char* to_string(G1YCType type) {
041     switch(type) {
042       case Normal: return "Normal";
043       case InitialMark: return "Initial Mark";
044       case DuringMark: return "During Mark";
045       case Mixed: return "Mixed";
046       default: ShouldNotReachHere(); return NULL;
047     }
048   }
049 };

And I have tried to replicate the same on the SA side so that one can 
easily understand and map the definitions on both the sides.

   27 public class G1YCTypeHelper {
   28
   29   public enum G1YCType {
   30     Normal,
   31     InitialMark,
   32     DuringMark,
   33     Mixed,
   34     G1YCTypeEndSentinel
   35   }
   36
   37   public static String toString(G1YCType type) {
   38     switch (type) {
   39     case Normal:
   40       return "Normal";
   41     case InitialMark:
   42       return "Initial Mark";
   43     case DuringMark:
   44       return "During Mark";
   45     case Mixed:
   46       return "Mixed";
   47     default:
   48       return null;
   49     }
   50   }
   51 }


Please let me know if this is still a concern for you.

Thanks,
Poonam

On 6/9/2014 10:38 AM, A. Sundararajan wrote:
> The pattern of enum within a class and toString helper to return 
> string description of it -- is used for many cases.
>
> Why not use enums with String accepting constructor and toString (or 
> new method called "toDescription()) override? You could have add 
> "Unknown" in these enums to map to an option that is available in VM 
> -- but not in SA.
>
> Since it is a debugger it is expected to work with incomplete info.. 
> so whereever you map a VM data structure element to java enum, you can 
> map unknown enum constants to "Unknown" on Java side.  Of course, if 
> there is a sentinel element defined in VM side, you could use that 
> itself - no need for "Unknown" in such cases.
>
> It'd nice to simplify that class-within-enum pattern...
>
> -Sundar
>
> On Saturday 07 June 2014 02:48 PM, Poonam Bajaj wrote:
>> Hi,
>>
>> Please review these changes for the bug 8046282 for JDK 9.  These 
>> changes add some definitions on the SA side and the supporting code 
>> on the hotspot side.
>>
>> Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046282
>>
>> Thanks,
>> Poonam
>>
>


More information about the serviceability-dev mailing list