RFR(S) : 8233745 : [JVMCI] TranslatedException should serialize classloader and module info

[Igor Ignatyev]

Doug, Vladimir,

thanks for your review, pushed.

-- Igor

> On Nov 8, 2019, at 2:38 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> Ok, I think the translated exceptions still convert the most important information. Looks good to me.
> 
> -Doug
> 
>> On 8 Nov 2019, at 20:33, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>> 
>> Hi Doug,
>> 
>> I've added the difference in string representations to the bug report, for the connivence, here is the part of the diff:
>>> < at app//jdk.vm.ci.hotspot.test.TestTranslatedException.encodeDecodeTest(TestTranslatedException.java:73) 
>>> < at java.base at 14-internal/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>> <...>
>>> ---
>>>> at jdk.vm.ci.hotspot.test.TestTranslatedException.encodeDecodeTest(TestTranslatedException.java:73) 
>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>> 
>> as you can see there is 'app/' for classes loaded by application loader  (and another '/' as in the tests are from unnamed module) and '@14-internal' for classes from system modules.
>> 
>> Thanks,
>> -- Igor
>> 
>>> On Nov 8, 2019, at 3:18 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>> Hi Igor,
>>> 
>>> To understand the bits lost in the translation as you describe below, can you please paste here or in the issue an example of before and after of a translated exception that looses info in the translation.
>>> 
>>> -Doug
>>> 
>>>> On 8 Nov 2019, at 00:33, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>> 
>>>> Good.
>>>> 
>>>> Tom and Doug should look on this.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 11/7/19 3:15 PM, Igor Ignatyev wrote:
>>>>> http://cr.openjdk.java.net/~iignatyev//8233745/webrev.00/index.html
>>>>>> 71 lines changed: 50 ins; 14 del; 7 mod;
>>>>> Hi all,
>>>>> could you please review the small patch which updates jdk/vm/ci/hotspot/TranslatedException to encode/decode StackTraceElement fields which were introduced in JDK9 (classloader name, module name and version fields)?
>>>>> I wasn't able to make deserialize StackTraceElement::toString to return the same string representation as original ones b/c StackTraceElement::declaringClassObject won't be set, as a result, JDK_NON_UPGRADEABLE_MODULE and BUILTIN_CLASS_LOADER bits won't be set either and StackTraceElement::toString will have classloader names even for built-it loader (won't be in original b/c dropClassLoaderName() is true) and version of system modules (won't be in original b/c dropModuleVersion() is true); so I changed how TestTranslatedException compares original and decoded exceptions.
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8233745/webrev.00
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8233745
>>>>> testing: compiler/jvmci/ + graal tiers
>>>>> Thanks,
>>>>> -- Igor
>>> 
>> 
>