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