Brian,

More information on this: I wrote an app that allocates VRAM or
AGP memory up to the limit on the system (on my system, that's
128 MB each of VRAM and AGP).  I ran this app twice (once
for VRAM usage, once for AGP usage) and checked the Task Manager.

In both cases, the process itself (my little app) took up about 3MB;
so none of the DirectX memory it allocated (128 MB) showed up as part
of the process footprint.

In the VRAM case, the 128 MB allocation didn't show up anywhere.  As
I thought (in my first mail), that's external memory that TaskManager
does not know about.

However, in the AGP case, that 128 MB showed up as part of the
"PF Usage" meter; my total amount allocated went up by that 128 MB
amount.  That memory did not show up in my process size or in any
other process, but the system noted that the memory usage overall went up.

I assume that what's happening here is a combination of:
- Windows does not report memory usage for internal OS processes.  So when
we ask DirectX to allocate memory for us, this is done in the DirectX
process
(or whatever process is managing DirectX or accelerated memory allocation).
So whereas TaskManager will report that the memory is being used, it won't
report who's allocated that memory.  I don't know whether the utilities
on sysinternals.com will help drill into that any more than this.
- VRAM usage is opaque to the system and the only way you can know
what's being used
there is by running some utility that queries DirectX directly.  This is
done
through the GraphicsDevice.getAvailableAcceleratedMemory() call in Java, and
is also done by native apps such as the DxCapsViewer utility provide
with the
various DirectX sdk's.
- AGP memory is just system memory that is pre-allocated to work with
the AGP
bus.  Since it's part of the overall system heap, allocating chunks of it
shows up in the system heap monitor (TaskManager).  I believe the amount of
system heap assigned to AGP memory is determined at boot time and that
you can
change this amount in your BIOS (or somewhere in your system).  From your
results, it sounds like there's an awful lot of heap space pre-allocated to
AGP (if that's truly what's going on in your app).

Hope that helps narrow down your problem.

Chet.


Chet Haase wrote:

Hi Brian,

There are a few utilities on sysinternals.com that purportedly do a
better job of tracking system information.  I haven't played with them
much, so I don't know if it has what you need, but it might be worth
checking them out.

Chet.


Brian Peterson wrote:

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".



===========================================================================

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