--
发件人：Florian Weimer
发送时间：2020年2月26日(星期三) 19:13
收件人：向伟(识月)
抄 送：hotspot-runtime-dev ; core-libs-dev
主 题：Re: VM crashed at StringTable expansion
* 向伟(识月):
> We create a simple case to reproduce the issue:
>
> import java.lang.reflect.Field;
> import java.lang.reflect.Mo
- Mail original -
> De: "向伟(识月)"
> À: "Florian Weimer"
> Cc: "core-libs-dev" , "hotspot-runtime-dev"
>
> Envoyé: Mercredi 26 Février 2020 13:45:52
> Objet: 回复：回复：VM crashed at StringTable expansion
> Hi Florian, Alan,
&g
On 26/02/2020 12:45, 向伟(识月) wrote:
:
It is an internal library, we may suggest the user to change their code.
But actually, it isn't easy to find the code if the other users have similar
usage.
If you with --illegal-access=debug then you'll get a stack trace that
should help you quickly identi
e crash or locate the problem in user code quickly.
Thanks,
Wei Xiang
--
发件人：Florian Weimer
发送时间：2020年2月26日(星期三) 20:08
收件人：向伟(识月)
抄 送：core-libs-dev ; hotspot-runtime-dev
主 题：Re: 回复：VM crashed at StringTable expansion
* 向伟(识月):
> Hi Florian,
>
> This isn't a common usage.
&
On 26/02/2020 11:40, 向伟(识月) wrote:
Hi Florian,
This isn't a common usage.
For the below code:
String s1 = "s1".intern();
f.set("s1".intern(), f.get("s2"));
After calling reflection, the value of s1 is changed to "s2".
In some special scenarios, the original jar file can't be modified. But the
* 向伟(识月):
> Hi Florian,
>
> This isn't a common usage.
> For the below code:
>
> String s1 = "s1".intern();
> f.set("s1".intern(), f.get("s2"));
>
> After calling reflection, the value of s1 is changed to "s2".
> In some special scenarios, the original jar file can't be modified. But the
> user
* 向伟(识月):
> We create a simple case to reproduce the issue:
>
> import java.lang.reflect.Field;
> import java.lang.reflect.Modifier;
> public class StringTableTest {
> public static void main(String[] args) throws Exception {
> Field f = String.class.getDeclaredField("value");
>
Hi,
cc'ing core-libs-dev as this seems to me like a case of "don't do
that!". Reflection can be used to "shoot oneself in the foot" and I
think that is the case here.
That said, if we can make the VM more resilient without penalizing all
the well behaved code, then we should probably do that
