Snippets responded to below...

On Mon, Jun 8, 2009 at 5:43 PM, Robert Lehr<robert.l...@gmail.com> wrote:
>
> I executed a simpler test in Java only, one that prints a simple
> "Sleeping 30sec" message then sleeps for 30sec.  The 30sec delay is so
> that I can record the memory allocated by JVM.
>
>    * on a Windows XP laptop a 2.2GHz dual-core CPU and 2GB RAM
>    * on several Linux v2.6 systems w/ 8 cores of ~2.6GHz and 16GB RAM
>    * on several Linux v2.4 systems w/ the same configs as those w/
> the v2.6 kernels
>
> All tests were executed w/ a v6 JVM.
>
> NOTE - Linux version numbers refer to the kernel's version.
>
> In short, only the linux v2.6 kernels showed the exorbitant
> memory-utilization that I reported previously.  On both Windows XP and
> Linux v2.4, the memory allocated was on the order of MBs, not
> HUNDREDS of MBs.
>
> NOTE - in practice, I consider the 10, 11 and 12MBs that I observed to
> be on the order of MBs, not TENs of MBs.
>

Can't reproduce:

[jo...@xxxxx ~]$ uname -a
Linux xxxxx 2.6.18-128.1.10.el5 #1 SMP Wed Apr 29 13:53:08 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
[jo...@xxxxx ~]$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)
[jo...@xxxxx ~]$ cat Test.java
public class Test
{
public static void main(String[] inargs)
{
  while(true)
  {
    System.out.println("Sleeping....");
    try {
      Thread.sleep(30000);
    }
    catch(Exception e) {
      System.out.println("Interrupted...");
      break;
    }
  }
}
}

[jo...@xxxxx ~]$ javac Test.java
[jo...@xxxxx ~]$ java Test &
[1] 28527
[jo...@xxxxx ~]$ Sleeping....
[jo...@xxxxx ~]$ ps -o comm,rss,vsz -p 28527
COMMAND           RSS    VSZ
java            15308 8533300
[jo...@xxxxx ~]$ Sleeping....
[jo...@xxxxx ~]$ ps -o comm,rss,vsz -p 28527
COMMAND           RSS    VSZ
java            15308 8533300

Care to post yours?


> One would guess then that the overcommit feature of the Linux v2.6
> kernel is causing this impression of exorbitant memory-utilization.
> The question remains then whether the overcommit affects the
> scalability of the JVM on Linux v2.6 systems.  IOW, for a simple
> program that causes the JVM to "allocate" hundreds of megs of RAM on a
> multi-gigabyte system, will the number of JVM instances be severely
> limited?  For example, if the JVM allocates 400MB on a 16GB system, is
> the total number of JVM instances limited to ~40 (16000/400 or to the
> ~1300 (16000/12) that I would otherwise expect.  I can explore that
> indepedently and share the results here later if anyone is interested.
>

Nah. Overcommit doesn't mean that, and it doesn't have anything to do
with the behavior you're seeing. I don't mean this as a criticism of
your analysis, but you're being fooled, something in your setup is
broken.

>
> Errrm - so Java's value is limited to large systems ?  That statement
> does not seem to take into account all of the small systems, including
> mobile devices, that use Java.  What am I missing here?
>

They're completely different platforms. Same language, a few
commonalities in platform API, but completely different runtimes. The
regular JDK that ships on desktops and servers is not close to
suitable for constrained memory systems, and the ME platform isn't
close to suitable for "enterprise" work.

>
> When a comparable C++ progie allocates 40k, I do not consider an
> initial allocation of 400MB to be acceptable for any system.  It's
> wasteful enough to begin reconsidering whether the benefits of the
> system in question are worth the cost.
>
> IOW, when I see a increase of 4 orders of magnitude of attribute A in
> exchange for 1 order of magnitude of improvement in attribute B, my
> alarms are triggered.  I do my value calculations, start asking
> questions and looking for something to kill.  In this case, the JVM
> allocating 400MB instead of 40k; I expected something on the order of
> MBs, not HUNDREDs of MBs.
>
> NOTE that the above comment is a general statement and does not
> reflect my observations of the v6 JVM on Windows XP and Linux v2.4.x.
>

Well, there is no way an SE JVM can take less than 16M for hello
world, but that said-, trust me, if you dig further you'll discover
some configuration issue that explains the discrepancy between 16M and
400M. :) No one would use Java if a minimal working set of 400M was
even a corner case possibility.

>
> True.  Except that I can compare these metrics to values obtained for
> corresponding programs in other languages and on similar OSes, i.e.,
> linux vs linux, Windows vs Windows.  A metric may not be accurate.
> But if it is applied consistently then it can be used for comparisons.
>

Well...the userspace visible metrics are inaccurate in *different
ways* across platforms, even (especially) between linux 2.4 + 2.6.
Nevertheless, agreed, for a trivial app the numbers should be
basically identical.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to