Re: Segmentation Fault and 1024-bit reselotion?
For what it is worth, I see the same problem under xfree86 at 16bpp, so I am not sure that it is an Xvnc problem. What is involved in adding support for new color depths? I would like to drop support for older versions of JDK for an application that I am developing that I would be willing to volunteer to help, if possible. Brandon Anderson wrote: Here is the results from xdpyinfo [snip] As you can see, the depth is really only 16 bits. But one thing that might be important to mention is that I'm not actually running X. I'm running Xvnc. I've tried the same program on an actual X console(just a second ago), and it seems to work. Any ideas on how I can get this to work in Xvnc, or does it sound like I'm just going to be screwed? Oh by the way, on a side not, everytime I run any program that uses awt classes I get the following warning a whole bunch of time. It doesn't seem to cause any problems but its starting to get annoying. [snip] > > Exception occurred during event dispatching: > > java.lang.InternalError: Unsupported 1024-bit depth > > > > at sun.awt.motif.X11Graphics.X11LockViewResources(Native Method) > > at sun.awt.motif.X11Graphics.lock(X11Graphics.java:797) > > at sun.java2d.loops.LockableRaster.lock(LockableRaster.java:163) > > at > > sun.java2d.loops.RasterOutputManager.convertFrom(RasterOutputManager.java:1414) > > at > > sun.java2d.loops.RasterOutputManager.performOpaqueBlit(RasterOutputManager.java:979) > > at > > sun.java2d.loops.RasterOutputManager.compositeSrcDst(RasterOutputManager.java:654) > > at > > sun.java2d.loops.RasterOutputManager.renderImage(RasterOutputManager.java:472) > > at > > sun.java2d.SunGraphics2D.renderingPipeImage(SunGraphics2D.java:2040) > > at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java:1634) > > at sun.awt.motif.X11Graphics.drawImage(X11Graphics.java:583) > > at javax.swing.JComponent.paint(JComponent.java:536) > > at java.awt.Container.paint(Container.java:770) > > at javax.swing.JFrame.update(JFrame.java:255) > > at > > sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java:248) > > at java.awt.Component.dispatchEventImpl(Component.java:2429) > > at java.awt.Container.dispatchEventImpl(Container.java:1032) > > at java.awt.Window.dispatchEventImpl(Window.java:714) > > at java.awt.Component.dispatchEvent(Component.java:2289) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:258) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:68) > > SIGSEGV 11* segmentation violation > > stackpointer=0x416f4e7c > > > > Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v2, green threads): > > "AWT-Finalizer" (TID:0x404c55f8, sys_thread_t:0x8681d98, state:CW) > > prio=9 > > at java.lang.Object.wait(Native Method) > > at java.lang.Object.wait(Object.java:424) > > at sun.awt.AWTFinalizer.run(AWTFinalizer.java:46) > > -- -- Rob Clark Dot Wireless, Inc. (858)552-2946 [EMAIL PROTECTED] --
java + X11 memory leak
I noticed something interesting the other day, which I think would qualify as a memory leak. Example: create an java.awt.Image instance... the some/most of the memory for the image is allocated under the X server process, but the VM does not take this memory into account when deciding whether to garbage collect. The result is that if you get rid of references to an Image, the memory under the X server process isn't freed until the Image object is gc'd, which doesn't happen because the VM is under it's threshold to begin garbage collection. The solution, I think, would be to keep track of memory used by XImage's, and count that towards the threshold used to begin garbage-collection. -- ------ Rob Clark Dot Wireless, Inc. (858)552-2946 [EMAIL PROTECTED] --
Re: java + X11 memory leak
Chris Abbey wrote: But is that memory allocated out of the chunk of VM reserved as the HEAP? I doubt it... I don't think it even blongs to the same process does it? Seems to me that it would have to belong to the Xserver's process... in the Xserver's address space and potentially on the Xserver's machine (as in a different machine than the JVM). By the same token if I go into native code by way of JNI and malloc 28Mb of main store, yes it comes out of the process address space that the JVM is running in, but it does not come out of the *heap*. The only thing that GC tracks in terms of memory usage is the amount of it's _reserved_ memory (the current heap) has been _commited_; at least on any JVM I've ever seen the guts of. You are correct that it is not allocated from the same heap. The problem is that it is an allocation of resources that isn't accounted for when deciding to garbage collect. (Have you ever seen a linux box come to it's knees just because X is using >100MB and your out of swap?) This is memory that is free'd when the Image object is gc'd, but if your java application it's using much memory allocated from it's heap, then the Image objects will never be gc'd. p.s. [OT] I sure wish people would stop posting this "text/alternate" stuff in public places... can a list serve be set to strip that tripe out I wonder? Oh, I'm sorry... that's my bad. Hopefully this email will be plain text. -- -- Rob Clark Dot Wireless, Inc. (858)552-2946 [EMAIL PROTECTED] --
Re: java + X11 memory leak (a crazy idea)
Here's a crazy idea: the whole problem, as I see it, arises because the JVM's garbage collector only knows of one resource pool, the heap, when in fact there are other resource pools outside the JVM that it should also concern itself with. Say, for example, you implement a class, FooBar, that is a wrapper for some legacy "C" code... when you create an instance of this class, it allocates some resource outside the JVM (memory, file handles, whatever). This object is using a resource that the JVM does not know about, but it is a resource that will be freed with the instance of the class is garbage collected. So, what I think the JVM needs is an extensible concept of resources... for example, sun could add to the System class the following method: public static synchronized void incrementResourceUsage( String resourceName, int amount ); The "amount" is generic... it is compared only to thresholds that can be set on the command-line, or in a properties file. So, when you instantiate FooBar, it increments the resource "foobar" the appropriate amount. If a threshold is exceeded, it causes garbage-collection, which will hopefully reduce the amount of the "foobar" resource in use. The finalize method for FooBar would increment the same resource by the appropriate negative amount. (This example is bad, because you normally wouldn't want the resource to be class specific... for example you would have a resource for memory allocated outside the JVM's heap (a wrapper for malloc() and free() would be the way to go, for the legacy code example), a resource for x-server resouces held, etc.) -- -- Rob Clark Dot Wireless, Inc. (858)552-2946 [EMAIL PROTECTED] --
Re: java + X11 memory leak (a crazy idea)
"Daniel W. Dulitz x108" wrote:
> Rob Clark writes:
> > Here's a crazy idea: the whole problem, as I see it, arises because
> > the JVM's garbage collector only knows of one resource pool, the
> > heap, when in fact there are other resource pools outside the JVM
> > that it should also concern itself with. [...]
> >
> > For example, sun could add to the System class the following method:
> >
> >public static synchronized void incrementResourceUsage
> > (String resourceName, int amount);
> >
> > [...] If a threshold is exceeded, it causes garbage-collection,
> > which will hopefully reduce the amount of the "foobar" resource in
> > use.
>
> I think that would work. But I have three comments. (1) Right now,
> Java has a way to explictly release external resources. You can
> either have a dispose() method in your class and call it at the
> appropriate time (the approach Sun took for graphics-related classes),
> or you can, as Chris suggests, call the finalizer explicitly at the
> appropriate time.
>
If I were sun, I would try and get away from explicitly releasing external
resources because (a) that is an implementation rather than interface issue,
and (b) you have to explicitly do something to release the resources. My
thoughts are that since java aims to be cross-platform, the developer should
not have to know that on some platforms an object may have external
resources associated with it, but not on others. Of course, this is just my
opinion.
>
> (2) incrementResourceUsage() adds a very specialized feature to all
> JVMs, but as you point out, it's difficult to solve all resource
> reclamation problems when using a single-purpose tool like "an
> unweighted integer sum of usage values exceeds a threshhold."
> System.forceGc() would accomplish the same thing much more flexibly:
>
> class ResourceHog {
> // ... whatever stuff you would ordinarily put in ResourceHog
>
> protected static int nInstances = 0;
> protected static final int nMagicInstanceThreshold = 50;
>
> public ResourceHog ( /* whatever */ ) {
> // ... whatever stuff you would ordinarily do
>
> if (++nInstances > nMagicInstanceThreshold) {
> // could also be conditional on other things
> System.forceGc ();
> }
> }
>
> public void finalize () { --nInstances; }
> }
>
> Or you could write a ResourceManager that would do all sorts of cool
> stuff for you.
>
> (3) incrementResourceUsage() would have all the same problems as
> System.forceGc(). In other words, it wouldn't work at all for some GC
> schemes, including conservative GCs. Conservative GCs never know for
> sure that a given reference is live -- they just know when it's dead
> (hence "conservative"). So no conservative GC can ever promise to
> garbage collect all objects that are at that point garbage. (Not to
> mention that "at that point" may be difficult to rigorously define in
> a multithreaded system.)
>
> That's why there is no System.forceGc() in Java, why System.gc() is
> merely a recommendation, and why incrementResourceUsage() is unlikely
> to be implemented.
I think the conservative GC isn't an issue... you have the same problems
whether the resource is allocated from the heap, or from some other resource
pool. All the incrementResourceUsage() does is extend the concept of
resource utilization to other (non-heap) resources, so that they don't go
un-accounted for. You could use the same interface to keep track of % of
heap used (although in implementation you may not want to for performance
reasons).
--
--
Rob Clark
Dot Wireless, Inc.
(858)552-2946
[EMAIL PROTECTED]
--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
