Christos Zoulas wrote:
On May 26, 3:20pm, michael.mcma...@sun.com (Michael McMahon) wrote:
-- Subject: Re: Review request for 5049299
| Christos Zoulas wrote:
| > Let's forget about the overcommit heuristics/settings alltogether.
| > We need a portable solution to the problem that works in all scenarios.
| > In addition the jvm maps memory on linux with MAP_NORESERVED which makes
| > the situation even more complicated. Yes, overcommit is useful
| > in a typical workstation setup, but not in a server environment where
| > deterministic behavior is desired.
| >
| >
| Christos,
|
| Can you elaborate on what you have in mind?
|
I don't have a good solution. The only option I see to to use
vfork(2) on systems that have it (*), and emulate it by suspending
the parent manually on systems that don't in order to achieve the
same process scheduling semantics. This of course takes away all
the vfork() benefits (speed/efficiency, avoiding the memory exhaustion
issues).
Unfortunately, vfork() on Solaris, won't do what we want to do.
vfork() cannot be used in multi-threaded apps, on Solaris.
So, I think we are stuck with different solutions for Solaris and Linux.
While it's not an ideal situation, at least it means we can still
have consistent behaviour across both operating systems.
- Michael
