RFR JDK-8046282: SA update

[Poonam Bajaj]

Hi Sundar,

Is it okay with you if I keep the enum and class definitions as they are 
now? And can I add you as the reviewer for these changes?

Thanks,
Poonam

On 6/9/2014 2:56 PM, A. Sundararajan wrote:
> Since SA is java code, we could have it cleaner..
>
> my 2 cents,
> -Sundar
>
> On Monday 09 June 2014 02:40 PM, Poonam Bajaj wrote:
>> 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
>>>>
>>>
>