You might want to use the -XX:+UseCompressedOops JVM option to compress the
JVM object pointer size in 64 bits.
On Wednesday, October 3, 2012 9:17:21 PM UTC+2, Thomas wrote:
>
> try and use a 32bit JVM. I found that a 64bit JVM uses almost twice as
> much memory. YMMV
>
> Thomas
>
--
You recei
You have 2 distinct problems:
- allocating many short-lived objects. It can affect performance but
does not matter for long-term memory occupation
- keeping too many things in memory. Then you have to resolve an
algorithmic question, quite independent of
the technology you use.
On Wed, Oct 3,
try and use a 32bit JVM. I found that a 64bit JVM uses almost twice as much
memory. YMMV
Thomas
--
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 modera
Hi,
We are running our medical hub product on a cluster of 7 nodes, mainly
Atom 330 cpus with 2gig of RAM, 32 bits JVM.
We manipulate heavy data structures, marshaling them back and forth between end
points. Never hit resource related problems.
You do not have much control on the JVM, you can t
cej38 writes:
>I have watched, listened-to, or read most of the stuff out there that
>is on how to tune your code to be faster (ie. type-hints). All of
>these pointers are great. It is useful to know. What I haven't seen
>is something similar about best practices for how to mak
I have watched, listened-to, or read most of the stuff out there that is on
how to tune your code to be faster (ie. type-hints). All of these pointers
are great. It is useful to know. What I haven't seen is something similar
about best practices for how to make your code use as little memory
