RFC: Netx - Check and store intial-heap-size and max-heap-size
Deepak Bhole
dbhole at redhat.com
Wed May 27 11:50:03 PDT 2009
* Omair Majid <omajid at redhat.com> [2009-05-27 14:17]:
> Deepak Bhole wrote:
>> * Omair Majid <omajid at redhat.com> [2009-05-26 13:53]:
>>> Any comments?
>>
>> Looks good.
>>
>> Have you given any thought to how these values will be used by the way?
>> The current design does not allow setting of heap sizes as the
>> application code runs from the same vm instance as 'javaws' itself. You
>> could make
>> it launch a new vm process I guess, but that'd be a bit messy, specially
>> since the security manager and stuff would need to be reset somehow,
>> which means the need for another wrapper..
>>
>
> I am thinking of an ugly hack here: add an option -Xnofork for
> net.sourceforge.jnlp.runtime.Boot. The first jvm reads everything and
> figures out that it needs to create another jvm. It then launches the
> second jvm with the relevant options and passes -Xnofork to
> net.sourceforge.jnlp.runtime.Boot (I am extending
> Launcher.launchExternal() to accept args to pass to the new jvm and the
> new java program) with the same jnlp file. This second jvm sees the
> -Xnofork option and ignores everything that requires a new jvm. Does
> that make any sense? That shouldn't affect security, should it?
>
Yeah, I really wanted to avoid the recursive call scenario.
It seems like the only option at the moment though. Okay then. I just
wanted to know if there was another possible workaround.
Cheers,
Deepak
>> Anyways, patch is good. Go ahead and commit any time.
>>
> Thanks for the review!
>
> Cheers,
> Omair
More information about the distro-pkg-dev
mailing list