Hi Chet,

I'll do the accounting of the images that you suggest and see what I get,
and thanks for the tip on flushing images.

The system gets all the memory only after stopping the Java process, no
other process.

Do you know of any memory analyzer that could help track down who has what
memory across the whole system?  Something that would help track down where
the other half-gig is comeing from when the Java process is terminated?


Brian

-----Original Message-----
From: Chet Haase
To: Peterson, Brian
Cc: [EMAIL PROTECTED]
Sent: 9/22/2004 10:21 AM
Subject: Re: [JAVA2D] Non-heap memory usage?


Brian,

There are a lot of mysteries in memory usage, both what is using what,
and how it is reported in TaskManager.

It is possible that we are using memory in other parts of the system;
for example, we use shared OS libraries that might allocate their
memory in another process entirely (and that thus would not show up
as attached to your process' heap).  But 1G is a lot of memory...

As for VRAM, I'm not sure that would hit the radar of TaskManager.  We
use DirectX to allocate memory on your video card, but I don't think
that
memory is tracked in either your process or any other; it's just an
extra
lump of memory attached to an external device (the GPU).  I really
doubt that TaskManager would report that memory as attached to anything
on the system (TM only deals with the system heap, as far as I know).

It might be possible that when we try to allocate more memory than you
have VRAM that the system starts allocating memory in "Non-Local Video
Memory", which is system memory accessible by the AGP bus.  It could
also be possible (just guessing here; haven't ever run tests on this)
that that memory is reported against the DirectX process, or some other
system process.

Still, 1G is a _lot_ of memory.  If you have a screen resolution of
1280x1024
and are allocating images of that size in 32bit color, it would take
about 200 images to suck up that kind of footprint.

Here's a couple of tests to run:
- When you create an image, note it's size (w x h x depth) and keep a
running total (maybe print it to the command line).  (Be sure to
subtract that number when an image goes out of scope...)
- When the app quits, is the current memory usage by images reflective
of the memory numbers you are seeing in TaskManager?

- Is there any other process in TaskManager that reports having that
kind of memory usage?  That is, when you see your system get
back 1G of memory after the app quits, where did it come from?

And here's a tip if you are using a lot of memory:
- don't hold onto images longer than you need to.  if the system
can GC them, you'll get back all of that memory in short order.
And look into using Image.flush() to flush any accelerated-memory
cache associated with a managed image or VolatileImage (if you aren't
using that image currently).

Chet.


Brian Peterson wrote:

>I have a graphics-intensive application that uses Java2D and
BufferedImage
>extensively on a Windows XP platform.  The Windows Task Manager tells
me
>that the java process is using about 300MB of memory, but when I exit
out of
>the application, the overall memory usage of the system drops by almost
1G.
>
>I have no experience with non-heap memory usage.  Could Java2D be using
>memory that is not accounted for in the process list of the Task
Manager?
>Could my graphics card be grabbing lots of memory?
>
>Any insights or suggestions would be greatly appreciated.
>
>Brian
>
>=======================================================================
====
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>of the message "signoff JAVA2D-INTEREST".  For general help, send email
to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to