RFR JDK-8046282: SA update

Poonam Bajaj poonam.bajaj at oracle.com
Mon Jun 16 09:15:30 UTC 2014


Hi Sundar,

I have updated the enum classes. The updated webrev is available here:
http://cr.openjdk.java.net/~poonam/8046282/webrev.01/

Please review the changes and let me know your feedback.

Thanks,
Poonam


On 6/12/2014 1:25 PM, Poonam Bajaj wrote:
> 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
>>>>>
>>>>
>>


More information about the serviceability-dev mailing list