RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64
Staffan Larsen
staffan.larsen at oracle.com
Wed Oct 9 11:53:52 PDT 2013
I can absolutely see where Aleksey (and 99% of the Java users) is coming from. From a user perspective there is no difference between the launcher arguments and the JVM arguments. Unfortunately the implementation does make a difference between them and it's not easy to hide this difference.
A similar problem is that the actual main-class is not known by the JVM. We work around this with the sun.java.command property, but when a custom launcher is used that property is not set and so we lack information about this in the JVM (and in the management APIs). The typical example of this for me is running eclipse.
Perhaps we could extend the JNI invocation API to allow these things to be passed through? A problem is of course to define what a "launcher argument" is. For example, sometimes Java is launched from inside another application (web browser, anyone?) and then the arguments to that host process makes little sense to pass on.
Regards,
/Staffan
On 9 okt 2013, at 11:21, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> On 10/09/2013 01:03 PM, Mandy Chung wrote:
>>> Do you see any better option?
>>
>> I no longer work in this area and don't have any suggestion at the
>> moment. Although parsing of VM name is not ideal, I suggest it as a
>> workaround for now and give the serviceability team time to look into
>> this to address your request.
>
> Ok, I'll leave the ticket open meanwhile.
>
> Thanks,
> -Aleksey.
>
More information about the serviceability-dev
mailing list