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

[Doug Simon]

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