Thread: RE: [Java-gnome-developer] Use of destroy()
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-developer
|
From: Jeffrey M. <Jef...@Br...> - 2004-10-28 11:01:59
|
I think destroy is a very valid method that can have many uses. In java-gnome it is just a direct call to the gtk libraries gtk_widget_destroy. This native method destroys the native widget, breaks any references it holds, and removes in from its' parent container (if it has a parent container). Calling destroy on a Dialog is a common task and we do it often in our examples. In our TestGTK example, all of the dialogs are closed with calls to destroy. -Jeff > -----Original Message----- > From: jav...@li... > [mailto:jav...@li...]On Behalf Of > Mark Howard > Sent: Wednesday, October 27, 2004 4:56 PM > To: Laurent Martelli > Cc: jav...@li... > Subject: Re: [Java-gnome-developer] Use of destroy() > > > Is there any time we would want to call destroy? > I think this is another example of the general bug that we > need to look into > more detail about the relationship between java objects and > gtk objects. How > should they be linked together. We've discussed it a lot in > the past and made > great improvements, but perhaps we still don't have the best solution. > > -- > .''`. Mark Howard > : :' : > `. `' http://www.tildemh.com > `- mh...@de... | mh...@ti... > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > java-gnome-developer mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer > NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended only for the use of the individuals or entity to which it is addressed. If you are not the intended recipient, or the person responsible for delivering the message to the intended recipient, please return or delete it immediately. Although this e-mail and any attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by us for any loss or damage arising in any way from its unauthorized modification or use. |
|
From: Jeffrey M. <Jef...@Br...> - 2004-10-28 11:03:43
|
I would be interested in taking a look at the code that caused the crash. I suspect that the call to destory is not what is causing the problem as we do this often in other applications. I am quite curious to locate the root cause of this problem. Would it be possible to post the code to this list? -Jeff > -----Original Message----- > From: jav...@li... > [mailto:jav...@li...]On Behalf Of > Laurent Martelli > Sent: Wednesday, October 27, 2004 8:54 AM > To: jav...@li... > Subject: [Java-gnome-developer] Use of destroy() > > > Hi, > > I've spent a few hours tracking down a bug in my application. It > crashed the JVM when I used escape to close a dialog. It turned out I > had a DialogListener which called destroy() on the dialog. It was > really a bad idea because gtk still had references on this dialog. > > So I'm wondering if it's a good idea to have that destroy() method in > the java API. It does not seem to be used internally by java-gnome and > can only give opportunities to the java developper to crash the JVM. > > -- > Laurent Martelli > la...@ao... Java Aspect > Components > http://www.aopsys.com/ > http://jac.objectweb.org > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > java-gnome-developer mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer > NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended only for the use of the individuals or entity to which it is addressed. If you are not the intended recipient, or the person responsible for delivering the message to the intended recipient, please return or delete it immediately. Although this e-mail and any attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by us for any loss or damage arising in any way from its unauthorized modification or use. |
|
From: Laurent M. <la...@ao...> - 2004-10-28 11:32:48
Attachments:
Destroy.java
|
It does not crash the JVM in that case (out of luck), but produces a critical GTK error message: (java-gnome:1903): Gtk-CRITICAL **: file gtkcontainer.c: line 1285 (gtk_container_foreach): assertion `GTK_IS_CONTAINER (container)' failed Remove the destroy() and all is fine. I must admit it is probably not very smart to destroy the source of an event when handling the event, but didn't know how to destroy the gtk object in an other manner. And it was not clear to me that gtk would do that itself. Jeffrey> -Jeff >> -----Original Message----- From: >> jav...@li... >> [mailto:jav...@li...]On >> Behalf Of Laurent Martelli Sent: Wednesday, October 27, 2004 8:54 >> AM To: jav...@li... Subject: >> [Java-gnome-developer] Use of destroy() >> >> >> Hi, >> >> I've spent a few hours tracking down a bug in my application. It >> crashed the JVM when I used escape to close a dialog. It turned >> out I had a DialogListener which called destroy() on the >> dialog. It was really a bad idea because gtk still had references >> on this dialog. >> >> So I'm wondering if it's a good idea to have that destroy() >> method in the java API. It does not seem to be used internally by >> java-gnome and can only give opportunities to the java developper >> to crash the JVM. >> >> -- Laurent Martelli la...@ao... Java Aspect Components >> http://www.aopsys.com/ http://jac.objectweb.org >> >> >> >> ------------------------------------------------------- This >> SF.Net email is sponsored by: Sybase ASE Linux Express Edition - >> download now for FREE LinuxWorld Reader's Choice Award Winner for >> best database on Linux. >> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >> _______________________________________________ >> java-gnome-developer mailing list >> jav...@li... >> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer >> Jeffrey> NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This Jeffrey> transmission is intended only for the use of the Jeffrey> individuals or entity to which it is addressed. If you are Jeffrey> not the intended recipient, or the person responsible for Jeffrey> delivering the message to the intended recipient, please Jeffrey> return or delete it immediately. Although this e-mail and Jeffrey> any attachments are believed to be free of any virus or Jeffrey> other defect, it is the responsibility of the recipient to Jeffrey> ensure that it is virus free and no responsibility is Jeffrey> accepted by us for any loss or damage arising in any way Jeffrey> from its unauthorized modification or use. -- Laurent Martelli la...@ao... Java Aspect Components http://www.aopsys.com/ http://jac.objectweb.org |
|
From: Jeffrey M. <Jef...@Br...> - 2004-11-01 14:07:39
|
I am working on 64 bit support now. Please see my earlier posting to see how I proposed to solve this problem. -Jeff > -----Original Message----- > From: jav...@li... > [mailto:jav...@li...]On Behalf Of > Robert Marcano > Sent: Saturday, October 30, 2004 1:25 PM > To: jav...@li... > Subject: Re: [Java-gnome-developer] Use of destroy() > > > On Sat, 2004-10-30 at 13:06, Jerry Haltom wrote: > > It does. The "problem" as I see it though is Java does not > allow you to > > store pointers natively: period. It's stored as an 'int' > now, which is > > guarenteed signed 32 bit on ALL PLATFORMS. There is discussion on > > changing it to a long, which is signed 64 bit ON ALL > PLATFORMS. There is > > no "native pointer". It would be nice though! THere is talk > on putting > > it in a long I think, or a class. I think they both suck > though. With a > > long you can't fit it all in a register, with a class you have to > > derefrence (vtable lookup). > > > > Another solution can be define both fields (int and long) and let the > native code decide which one to use. But will the performance increase > enough to allow the extra memory usage? > > ________________________________________ > Robert Marcano > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > java-gnome-developer mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer > NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended only for the use of the individuals or entity to which it is addressed. If you are not the intended recipient, or the person responsible for delivering the message to the intended recipient, please return or delete it immediately. Although this e-mail and any attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by us for any loss or damage arising in any way from its unauthorized modification or use. |
|
From: Jerry H. <wa...@la...> - 2004-10-30 14:35:16
|
I've been pondering how the mapping system could change dramatically. My idea involves storing the mapping in C. Keep a Java Object -> GObject hash structure of some kind. We would keep a ref on the GObjects. If there is a way to participate in the GC call, we could scan the map for ref count 1's, and unref them. If not, we'd need our own GC process. |
|
From: 'Mark H. <mh...@ti...> - 2004-10-30 15:00:36
|
On Sat, Oct 30, 2004 at 02:23:34PM +0200, Laurent Martelli wrote: > Mark> - Java objects are GCd when they go out of scope, unless > Mark> events have been registered. Therefore, c objects can exist > Mark> without corresponding java objects. > > I believe this not a problem, and anyway there's probably nothing that > can be done against it since some gtk objects may create ither gtk > objects on their own. It's all right as long they destroy them when > they are destroyed themselves. I agree in this patricular case. But what about when we create a window, hide it and then the java object goes out of scope. The c objects are still three and we have no way of accessing them. This is a memory leak. > By the way, when we want to get a reference on such an object from > java, we seem to always get an instance of org.gnu.gtk.Widget. It > would be nice to get the actual instance so that more useful things > can be done with the widget. I'll fill a bug report against that. I thought there already was a bug about this. Not sure. I agree, libglade.getWidget should do an appropriate cast. I'm not sure how simple that would be though. > What about the finalize method which is called when a java object is > garbage collected ? I think should call g_object_ref() when a java > object is created so that we are pretty the C object won't be > destroyed as long as the java object exists, and g_object_unref() in > finalize(). This way, a C object would destroyed when no java objects > references it and it's not referenced by a any C object either. When we add event handlers, we create references from the c object to the java object. I think we would almost always get the unfortunate case where the c object and java object reference each other, but nothing else references them. i.e. a memory leak WeakReferences might seem the obvious answer, but it isn't -- in this case we would always have to keep references to any java objects which we have defined events in. What we really need is a weak reference which looks at both java references and g_object_refs. It might be possible for us to create this. > This only problem would be if a C object is manually destroyed while > there are still references on it (ref_count>0). This shouldn't happen. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... |
|
From: Laurent M. <la...@ao...> - 2004-10-30 15:33:59
|
>>>>> "'Mark" == 'Mark Howard' <mh...@ti...> writes: Mark> On Sat, Oct 30, 2004 at 02:23:34PM +0200, Laurent Martelli Mark> wrote: Mark> - Java objects are GCd when they go out of scope, unless Mark> events have been registered. Therefore, c objects can exist Mark> without corresponding java objects. >> I believe this not a problem, and anyway there's probably >> nothing that can be done against it since some gtk objects may >> create ither gtk objects on their own. It's all right as long >> they destroy them when they are destroyed themselves. Mark> I agree in this patricular case. But what about when we Mark> create a window, hide it and then the java object goes out of Mark> scope. The c objects are still three and we have no way of Mark> accessing them. This is a memory leak. Unless we unref in finalize(). >> By the way, when we want to get a reference on such an object >> from java, we seem to always get an instance of >> org.gnu.gtk.Widget. It would be nice to get the actual instance >> so that more useful things can be done with the widget. I'll fill >> a bug report against that. Mark> I thought there already was a bug about this. Is it http://bugzilla.gnome.org/show_bug.cgi?id=155075 ? It's not only a glade problem. Bin.getChild() is also affected. Mark> Not sure. I agree, libglade.getWidget should do an appropriate Mark> cast. I'm not sure how simple that would be though. >> What about the finalize method which is called when a java object >> is garbage collected ? I think should call g_object_ref() when a >> java object is created so that we are pretty the C object won't >> be destroyed as long as the java object exists, and >> g_object_unref() in finalize(). This way, a C object would >> destroyed when no java objects references it and it's not >> referenced by a any C object either. Mark> When we add event handlers, we create references from the c Mark> object to the java object. I think we would almost always get Mark> the unfortunate case where the c object and java object Mark> reference each other, but nothing else references Mark> them. i.e. a memory leak I had not thought of that. But the GC is supposed to also work in the case of circular references. Unless the the reference create in C is a root object for the GC. But it would seem normal that the programmer must unregister from events when a widget is not used anymore and is meant to be garbaged. Mark> WeakReferences might seem the obvious answer, That's what I was about to say :-) Mark> but it isn't :-( Mark> -- in this case we would always have to keep references to any Mark> java objects which we have defined events in. I must admit I don't see the point. To me, weak refs are really a solution. I guess I do not see the whole picture. Mark> What we really need is a weak reference which looks at both Mark> java references and g_object_refs. It might be possible for us Mark> to create this. >> This only problem would be if a C object is manually destroyed >> while there are still references on it (ref_count>0). Mark> This shouldn't happen. If gtk does not do this, then we can assume it can't happen if we remove destroy() from the java API. -- Laurent Martelli la...@ao... Java Aspect Components http://www.aopsys.com/ http://jac.objectweb.org |
|
From: Jerry H. <wa...@la...> - 2004-10-30 15:01:43
|
You're right. What I meant was that we have NO way to manage memory in Java. It happens behind the scenes, on a GC process. So, we need to either tie into this process, which I don't think we can, or have our own "cleanup" process to delete C instances when the Java instance dies. This is the ref count idea. We scan our map, find items with a dead Java instance, and unref them, and remove them from the map. We are no longer using them. Our Java wrapper instances will stay alive as long as there is a reference to them. After they loose all references, they will die at some undetermined time in the future. If the object is being used in a signal handler, it will not be GC'd. You're C++ way of storing it in the data of the GObject is good... however, we need a way to map Java->Object to GObject as well. Java also conveniently lacks an efficient way to do this. |
|
From: Robert M. <ro...@ma...> - 2004-10-30 15:16:59
|
On Sat, 2004-10-30 at 11:01, Jerry Haltom wrote: > You're right. What I meant was that we have NO way to manage memory in > Java. It happens behind the scenes, on a GC process. So, we need to > either tie into this process, which I don't think we can, or have our > own "cleanup" process to delete C instances when the Java instance dies. > This is the ref count idea. We scan our map, find items with a dead Java > instance, and unref them, and remove them from the map. We are no longer > using them. There is a way to get information about the reachability of a Java object, Someone knows about the status of this classes on GNU Classpath? http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/ReferenceQueue.html > > Our Java wrapper instances will stay alive as long as there is a > reference to them. After they loose all references, they will die at > some undetermined time in the future. If the object is being used in a > signal handler, it will not be GC'd. > > You're C++ way of storing it in the data of the GObject is good... > however, we need a way to map Java->Object to GObject as well. Java also > conveniently lacks an efficient way to do this. ________________________________________ Robert Marcano |
|
From: Jerry H. <wa...@la...> - 2004-10-30 17:06:59
|
It does. The "problem" as I see it though is Java does not allow you to store pointers natively: period. It's stored as an 'int' now, which is guarenteed signed 32 bit on ALL PLATFORMS. There is discussion on changing it to a long, which is signed 64 bit ON ALL PLATFORMS. There is no "native pointer". It would be nice though! THere is talk on putting it in a long I think, or a class. I think they both suck though. With a long you can't fit it all in a register, with a class you have to derefrence (vtable lookup). |
|
From: Robert M. <ro...@ma...> - 2004-10-30 17:25:00
|
On Sat, 2004-10-30 at 13:06, Jerry Haltom wrote: > It does. The "problem" as I see it though is Java does not allow you to > store pointers natively: period. It's stored as an 'int' now, which is > guarenteed signed 32 bit on ALL PLATFORMS. There is discussion on > changing it to a long, which is signed 64 bit ON ALL PLATFORMS. There is > no "native pointer". It would be nice though! THere is talk on putting > it in a long I think, or a class. I think they both suck though. With a > long you can't fit it all in a register, with a class you have to > derefrence (vtable lookup). > Another solution can be define both fields (int and long) and let the native code decide which one to use. But will the performance increase enough to allow the extra memory usage? ________________________________________ Robert Marcano |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X