Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Swing faster than AWT?? ZHUH?  (Read 8112 times)
0 Members and 1 Guest are viewing this topic.
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Posted 2003-01-06 07:49:15 »

HOLD YOUR HORSES, I haven't discovered anything yet! Ranting beware.

I have been hacking both AWT and SWING for awhile to get the best performance out at the same time as I learn OpenGL.

My problem initially was that there were too many useless threads going on at the same time along with my rendering thread and they were all unneccessary.    

Now Sun seems to have very user friendly way of treating developers: http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html#why
However, I'd really like to be incontrol of the things that I do. To me this is crap news, if Swing is supposed to eventually take over the position of AWT it must be fully customizable and I want to be in control of every single thread running. And yes this means the hidden threads that might phuck up the program. If my program freezes, it is clearly my fault, not suns fault and thats why they should leave as much room for me.

Now, there is tons and metric tons of air inside of swing, we are all aware of that, thats why it is slow and people on slower computers can see delays when they click things. For game programming this is not necessarily so.  I admit that the hidden threads make my life 1000% easier, but the problem is that I don't want to do it the easy way. I want it the fast way.

Now here is the possible sollution:
 * invokeLater(): Requests that some code be executed in the event-dispatching thread. This method returns immediately, without waiting for the code to execute.
     
   * invokeAndWait(): Acts like invokeLater(), except that this method waits for the code to execute. As a rule, you should use invokeLater() instead of this method.

As you can clearly understand where I'm going with this. As a matter of a fact, I haven't found any reasonable way to access the inner threads in AWT and assuming that a lot of air could be squeezed out if we could access them this article explains everything better:
http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html

Although things are made easy for us, it doesn't mean that they are necessarily slow.  By accessing the swing thread, this saves us one thread, which can be many milliseconds and it will also save the GC from extra work.

I'm not saying swing is the way to go. I'm saying that swing has potential. If it *just* gave me greater degree of freedom. http://billharlan.com/pub/papers/Improving_Swing_Performance.html.

Now some people would say that omg all this for just one thread? Well, to me even one thread is enough. When I know that my code potentially runs faster in theory, it is enough for me and isn't everyone saying that Java is too slow? It is slow, certainly slower than C++, thats why to match we must counter the speed gap.

I know we are still light years away, but every single bit helps. I'm not trusting the Sun to make it faster with those policies. I don't care if an idiot can make a game if it is slow.

The practical uses for hacking the event thread? In theory, you could create game events, that would be handled among the input events or directed into another thread which is the actualy game thread.

The way I categorize things:

Under the hood threads:
-The engine
--Rendering
--Input
--Media(Sound)

These are currently all different threads, except for the sound. If they could be combined, that would be already 1 thread less.


Game threads
-events in game
-physics
-interaction

-Usually combined into one. Now this is what it should be.

The ideal way to render in games: The engine pumps out as much FPS as it is possible, the game thread and the input thread corresponds with the engine, and handles everything so that it goes maximium 72 fps(or whatever the eye/monitor relationship is). Now if the FPS is over 1000, which I'm having right now with my small OpenGL app,  the animation is not good looking. Thats why the animation speed must be limited to 72 fps, at the same time with the input thead. Now one lower end computers, the engine must keep count on the FPS part, since if the FPS goes lower than 72fps, the other threads must be adjusted too, so that the game maintains its playability.

This is certainly better design than having everything set to whatever FPS or the infinite fps loop.

So threads required would be:
1.) The graphics engine thread
-This would adjust the engine speed and everything else

2.) The game thread
-follows the engine thread.and keeps the game playable even on lower end systems.

This would help in 2d, but I'm aiming into the third dimensions, be the API opengl or java3d, that doesn't matter. To get the most speed out of the APIS we must have as secure base as possible, this means we must have go as lowlevel as possible so that the higherlevel api is able to take the full advatange of the environment.

Now when using Java2D or other java-based API, we don't have to worry about heavyweight/lightweight relationship since on swing, if done correctly, hardware acceleration is easy to do.

Now if we don't want the lightweight rendering, what now? I will continue when I find out more.

If you read this, please correct all the mistakes I have made in the concepts.  Do you have anything to add, howabout comparsion to AWT?
Offline SpongeBob

Junior Duke




Who lives in a pinnapple under the sea


« Reply #1 - Posted 2003-01-06 14:41:07 »

I have nothing to add in comparing AWT to Swing.  I only want to add the question again if anyone has ever tried using SWT for game development?  The reason for asking is the same as your point: getting it done quickly.  AWT calls native widgets which have always been quicker than Swing and I dont see that changing.  But like you said, AWT and Swing both hide handling of the event and display thread from the user.  SWT, from my reading, does not have this limitation.  Events have to be polled manually like writing a C app.  This may make SWT harder to use compared to AWT, but there is probably some serious speed gains.
Offline Kevdog

Junior Duke





« Reply #2 - Posted 2003-01-06 19:22:18 »

Hopefully old news to all of you, but beware:

When using invokeLater() or invokeAndWait() if you are creating a temporary object to run a command, make sure you subclass runnable, and not Thread.  Subclassing thread will leave all the thread objects you created in the unrun state, so they hang around.  

The application I'm working on now had 100's of calls to invokeLater() with a subclass of Thread and by the end of the day we'd have 10's of thousands of unrun threads hanging around.  Not sure on the performance implications of this.

I only bring it up because some "tutorials" on the web have invokeLater using a subclass of Thread, rather than Runnable!

There are only 10 types of people, those who understand binary and those who don't!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2003-01-06 22:15:06 »

Er, Kevdog, Thread is a Runnable - I suggest you go and find out what the bug is in your code and change your advice!

And everyone - just forget about using Threads in games, and then you won't have to ask questions about them Smiley

Cas Smiley

Offline GergisKhan

Junior Duke




"C8 H10 N4 O2"


« Reply #4 - Posted 2003-01-07 00:59:55 »

Just one question then.  If we really don't want to use threads in a game, how should we deal with multi-sample sound?  Or MP3s?  or anything like that?


gK

"Go.  Teach them not to mess with us."
          -- Cao Cao, Dynasty Warriors 3
Offline cknoll

Junior Duke




Flame On!


« Reply #5 - Posted 2003-01-07 01:23:06 »

I believe he is referring to 1 'developer' created thread.   It's true, when you send a sound stream to the sound card, an external thread is going to manage the feeding of the stream into the card, blah blah blah, but just like frame-related problems with multiple threads, you also will have the same problem synchronizing audio to the game if you have mulitple threads telling sounds to fiire at various times.  The synchronization overhead is complex to keep it together, it's better to have 1 thread for render->tick process (AI thinks)->player moves->render loops.  At this point, multi-processor systems are a weak argument because I don' tthink there's a JVM out there that handles it well, and it's not really your desktop configuration for a game machine.

-Chris
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #6 - Posted 2003-01-07 03:18:31 »

Quote
Er, Kevdog, Thread is a Runnable - I suggest you go and find out what the bug is in your code and change your advice!

And everyone - just forget about using Threads in games, and then you won't have to ask questions about them Smiley


Smiley

Yes, but a Runnable is not a Thread. And a Runnable is sufficient. So kevdogs advice is deeply true.

And - please don't forget about threads in games. One of Javas biggest strengths is it's awareness of multithreading. Hard to do network programming without! Hard to do on-the-fly resource-loading without! But handle them with care, you are always in danger!

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #7 - Posted 2003-01-07 06:41:37 »

Quote


Smiley

Yes, but a Runnable is not a Thread. And a Runnable is sufficient. So kevdogs advice is deeply true.

And - please don't forget about threads in games. One of Javas biggest strengths is it's awareness of multithreading. Hard to do network programming without! Hard to do on-the-fly resource-loading without! But handle them with care, you are always in danger!



My preminary tests show that I have recieved 7% speed increase in my application(using j3d timer) when taking out one thread and using the invoke later, and I was using runnable.

Princec came out of the closet to say this:
And everyone - just forget about using Threads in games, and then you won't have to ask questions about them

On the other hand you are developing java games, am I correct? If you don't use any of the java properties and if you go with lwgl as well, I don't see any reason to program with java at all sine everything could be done in c++, isn't that true?

Now the invoke later things are not perhaps the most clean way to handly your code, but I got to thinking this when I was doing it.

Is System timer used somewhere in the thread class? I hope not.

Now I'd like to go what SpongeBob said:
When working with games, you are most likely going to use only the frame, and then do some sort of active rendering on top of it.

Now JFrame is heavyweight and it doesn't differ much from the Awt window, except that its swing and has some swing properties that you can disable.  What I tried to say is that there might not be that much difference in between awt and swing. I'm tired now, I will come back later.

Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #8 - Posted 2003-01-07 08:15:52 »

Quote

On the other hand you are developing java games, am I correct? If you don't use any of the java properties and if you go with lwgl as well, I don't see any reason to program with java at all sine everything could be done in c++, isn't that true?


That's exactly what I always try to point out.....
Kiss

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline SpongeBob

Junior Duke




Who lives in a pinnapple under the sea


« Reply #9 - Posted 2003-01-07 10:46:38 »

Quote
My preminary tests show that I have recieved 7% speed increase in my application(using j3d timer) when taking out one thread and using the invoke later, and I was using runnable.


As for streaming media or network traffic Sun has came up with a solution to avoid using threads: NIO.  Sun specifically stated that threads were an issue and thus created NIO to solve the problem:

http://www.javaperformancetuning.com/tips/nio.shtml

Quote
I don't see any reason to program with java at all sine everything could be done in c++, isn't that true?


LWGL, from my understanding, is an API.  Almost all the standard Java API commands call back to a C/C++ equiv.  Using these APIs, Java programmers get native capabilities without leaving the ease of the Java language.  Yes, you can do everything in C/C++ that you can do in Java.  But then again, you can do everything in machine language or assembly that you can do with C/C++.  Would you want to?

Quote
Now JFrame is heavyweight and it doesn't differ much from the Awt window, except that its swing and has some swing properties that you can disable.  


JFrame, like all Swing components, are layered.  These layers effect speed.  Thats why JFrames are slower then AWT Frames.  And from my understanding of JFrame, the extra Swing stuffing cannot be disabled either.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2003-01-07 13:00:28 »

Eeeeh, always ready to throw the baby out with the bathwater! Bloody engineers and their binary world views eh?

I use most of Java's most useful features, and don't use the wrong ones at the wrong times. I use Java because it's easier than C++, I write code faster, and I find bugs in it faster, and that's the only reasons, really. But they seem like the best ones.

Cas Smiley

Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #11 - Posted 2003-01-07 13:23:00 »

Quote


As for streaming media or network traffic Sun has came up with a solution to avoid using threads: NIO.  Sun specifically stated that threads were an issue and thus created NIO to solve the problem:

http://www.javaperformancetuning.com/tips/nio.shtml


LWGL, from my understanding, is an API.  Almost all the standard Java API commands call back to a C/C++ equiv.  Using these APIs, Java programmers get native capabilities without leaving the ease of the Java language.  Yes, you can do everything in C/C++ that you can do in Java.  But then again, you can do everything in machine language or assembly that you can do with C/C++.  Would you want to?



JFrame, like all Swing components, are layered.  These layers effect speed.  Thats why JFrames are slower then AWT Frames.  And from my understanding of JFrame, the extra Swing stuffing cannot be disabled either.




I understand what you mean, but you can set the repaint off, and just add to the content pane, or even use the window itself. Thats what I do. I disabled the passive rendering on the frame, and then added my opengl canvas on top of it and it works great. However, my knowledge stops here. This means that I might be completely wrong, but 7% performance boost seems reasonable to me.
Offline SpongeBob

Junior Duke




Who lives in a pinnapple under the sea


« Reply #12 - Posted 2003-01-07 13:43:05 »

Quote

I understand what you mean, but you can set the repaint off, and just add to the content pane, or even use the window itself.


That works but what would the point be.  You have just turned a Swing JFrame into the equiv of a Java AWT Frame without the ability to display swing components or use its own graphical context.  At that point, wouldnt it just be as easy to use the AWT Frame?
Offline SpongeBob

Junior Duke




Who lives in a pinnapple under the sea


« Reply #13 - Posted 2003-01-07 14:21:15 »

Can you submit a code example of this modified Swing JFrame?
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #14 - Posted 2003-01-07 14:39:18 »

Yes when I'm sure that it is swing and not some other thing. I will PM you when it is on the source code section.

I didn't quite understand how you can replace threads in games with NIO. Could you direct me to any decent source where this would be done?

Offline cknoll

Junior Duke




Flame On!


« Reply #15 - Posted 2003-01-07 14:48:45 »

RE: replacing threads using NIO.

Disclaimer: I am going on my experience with using select sets in my old unix days of programming and also my experience using sockets in Java, but here goes:

In networked games, you'll have many clients connecting to a server.  In Java (before NIO), for each client there would be a thread that would block on a socket, so 6 clients would consume 6 threads on the server.

Enter NIO:  With NIO, you have the concept of selectors and channels.  You can have all the client connections set up as channels in a selector, and the selector will tell you which sockets have input ready to be read.  So, your NIO game architecture has 2 threads: one that listens for connections and puts new connections into a channel, and the main game thread that does everything else.  The game loop would look like this:

Render->AI Thinks->Process user input (read any available input from clients)->Render (loop)

Hence,  threads are eliminated using NIO.

-Chris
Offline Captain-Goatse

Junior Duke




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #16 - Posted 2003-01-07 16:10:45 »

OK I got it, I found example JCanyon or whatever and it is doing bunch of the same stuff that I'm doing also. Perhaps I shall investigate that closer, but boy is the code hard to read.
Offline Kevdog

Junior Duke





« Reply #17 - Posted 2003-01-08 18:02:10 »

Yep, a Thread is a Runnable, but a Runnable is not a Thread Smiley  Thread has a lot more overhead.

Note: You wouldn't do this in a render loop anyway because of the object creation....

On the web I found references to code like:
Thread t = new Thread() {
   public void run() {
       // do something
   }
};

SwingUtilities.invokeLater(t);

This leaves an unread thread hanging around, even after the "do something" code has executed because you never run start() on the thread.

Doing the same thing but with Runnable doesn't have that problem.

There are only 10 types of people, those who understand binary and those who don't!
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2003-01-08 18:49:53 »

Hm, AIUI a Thread creates no native peer until it is start()ed, and in either case, should be garbage collected just like a Runnable. (I'd be using a Runnable myself but there's no real harm in using a Thread for this if that's what you happen to have lying around, is what I'm saying, but I concede)

Cas Smiley

Offline Kevdog

Junior Duke





« Reply #19 - Posted 2003-01-08 20:08:58 »

A Thread is not garbage collected until it has been started.  But invokeLater doesn't start the thread, it only executes what is in the run() method.  So the thread is left in the unrun state, even though the run() method has been executed, so therefore it is never garbage collected.

Try it in a profiler, you'll see the Thread hanging around forever.  I'm really not sure what effect 10's of thousands of unrun threads has on performance, but I'm sure it's still not a good thing Smiley

There are only 10 types of people, those who understand binary and those who don't!
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2003-01-08 20:21:45 »

I'm almost certain that's incorrect behaviour, as a Thread is an Object like any other and should be collectable once there are no strong references to it any more. Unless invokeLater() is keeping hold of them...?

Cas Smiley

Offline cknoll

Junior Duke




Flame On!


« Reply #21 - Posted 2003-01-08 22:53:53 »

I'm with cas, unless you can demonstrate that creating threads objects and overriding their run method for use in an invokeLater() call does NOT let the object get GC'd.  Runnable just says your class must implement a method named run().  Threads have nothing to do with it.  invokeLater() is just using the appropriate interface for clients to implement if they want some action performed later.

The Swing event thread should remove references to any object that was 'registered' with it to invoke later via the invokeLater() call.  If the object isn't being GC'd there's another reference to the object somewhere.

-Chris
Offline sma

Junior Duke





« Reply #22 - Posted 2003-01-09 09:21:13 »

Regarding SWT: While I'm a big fan of SWT, I don't really see how this framework would help developing game GUIs.

  • You can't use it for applets.
  • You can't go "full screen" or change the display mode.
  • You get these "boring" native controls (a good thing for business application but let's say for a fantasy RPG I'd like to see some medieval-looking UI).
  • Drawing performance isn't always better.

On Windows, drawing on an SWT canvas seems to be a little bit faster than drawing on an AWT canvas as it directly uses GDI calls and has a better damage redraw strategy. It's however not faster than Java2D calls which might use a lower level hardware accelerated API. On Linux, SWT seems to draw noticable slower than pure Java.

Whatever, some ideas:

One could of course create own custom drawn buttons, input fields, list boxes, etc. with any skin you could possible want (I'd even call this easy to do).  Unfortunately, SWT's drawing capabilities are primitive compared to the 2D API. There's for example no easy way to do transparency and no way I know to load a custom font.  On the other hand, you have full access to all platform fonts and platform font rendering like subpixel antialiasing.

If you don't care about using the lower level AWT methods, namely the Java2D API, you could combine its power with SWT.  This might the best way to go but it requires Java 2. If you can live without advanced 2D graphics, you could use gcj to compile an executable.

Another interesting idea might be to combine something like the LWGL with SWT. I'd assume that LWGL eventually draws upon a Windows GC. This is directly exposed in SWT so you could probably efficiently combine 3D hardware accelerated graphics with SWT.

This is something a lot of people might be interested in IIRC the comments on the eclipse.tools newsgroup. I've however no knowledge about 3D and can't estimate whether such a combo would be difficult.

Stefan

.: Truth Until Paradox!
Offline SpongeBob

Junior Duke




Who lives in a pinnapple under the sea


« Reply #23 - Posted 2003-01-09 11:53:33 »

Quote

You get these "boring" native controls (a good thing for business application but let's say for a fantasy RPG I'd like to see some medieval-looking UI).


I have never found Swing and AWT widgets all that exciting either.

Quote

On Linux, SWT seems to draw noticable slower than pure Java.


Are you using SWT for Motif or GTK?  Java AWT components always use Motif.  I might be wrong here but I think Motif is faster then GTK at rendering widgets due to the GTK being several layers further from X-Windows compared to Motif (all that skinning stuff has to hurt performance too).  I think the Motif side of SWT will become deprecated some day though.  Sad

Quote

If you don't care about using the lower level AWT methods, namely the Java2D API, you could combine its power with SWT.  


There are ways to get Java 2D in SWT:

http://holongate.nerim.net/

I have never tried it but it looks interesting.

Quote

If you can live without advanced 2D graphics, you could use gcj to compile an executable.


At last I checked GCJ has no widget set at all.  

Quote

This is directly exposed in SWT so you could probably efficiently combine 3D hardware accelerated graphics with SWT.


I can see that.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2003-01-09 12:41:48 »

If you want pure performance and no frills, use pure LWJGL.

If you want to mix a Java GUI with high-performance OpenGL, use GL4Java and AWT or Swing.

If you want plain old 2D for games or applets, stick to AWT and Java2D. Use Swing if you want nicer controls.

If you want to write productivity applications then SWT will probably work just as well as AWT.

Cas Smiley

Offline rreyelts

Junior Duke




There is nothing Nu under the sun


« Reply #25 - Posted 2003-01-09 13:51:58 »

I'm with cas, unless you can demonstrate that creating threads objects and overriding their run method for use in an invokeLater() call does NOT let the object get GC'd.

You and Cas are missing the point. SwingUtilities.invokeLater() only asks for a Runnable, because it's not going to create a new thread - it's just going to execute the Runnable on the event thread. Subclassing Thread, in this case, gains you no advantages whatsoever and is extremely gratuitous at best, especially considering that it is directly associated with heavyweight operating system resources - which is probably why Thread objects aren't garbage collected until after the native operating system thread has been started and finished executing (at least on the VMs I have worked with). Don't believe me? Run this code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
import java.io.*;

public class ThreadTest {

  public static void main( String[] args ) throws Exception {
    final int total = 1000;
    for ( int i = 0; i < total; ++i ) {
      Runnable r = new Runnable() {
        public void run() {
        }
        public void finalize() {
          System.out.println( "Runnable finalized." );
        }
      };
    }
    for ( int i = 0; i < total; ++i ) {
      Thread t = new Thread() {
        public void run() {
        }
        public void finalize() {
          System.out.println( "Thread finalized." );
        }
      };
       // t.start()
    }

    BufferedReader r = new BufferedReader( new InputStreamReader( System.in ) );

    while ( true ) {
      System.out.println( "Enter \"gc\" to garbage collect or \"q\" to quit." );
      String command = r.readLine();
      if ( command == null ) {
        continue;
      }
      command = command.trim();
      if ( command.equals( "q" ) ) {
        break;
      }
      else if ( command.equals( "gc" ) ) {
        System.out.println( "Garbage collected." );
        System.gc();
      }
      else {
        System.out.println( "Command not understood." );
      }
      System.out.println();
    }
  }
}


You'll see the Runnables are all collected, but the Threads will never be collected, no matter how many times you request GC and how long you wait. Stick a t.start() in there, and all of the sudden all of your Threads will get collected.

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2003-01-09 21:45:00 »

No, we're not missing the point. The Threads should be garbage collected, and if they aren't, it's a bug, or a contradiction in the specification.

And the contract of invokeLater is that it takes a Runnable, and therefore it should be no problem to pass it anything I like that implements a Runnable. It might happen to be a Thread.


Cas Smiley

Offline rreyelts

Junior Duke




There is nothing Nu under the sun


« Reply #27 - Posted 2003-01-10 00:11:21 »

No, we're not missing the point.

Cas, you're just like Chris. Talking to you guys is like talking to a brick wall. You both can just be so thick. Smiley

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline leknor

Junior Duke




ROCK!!!


« Reply #28 - Posted 2003-01-10 02:00:41 »

Ok, we all know an Object isn't collected unless it isn't "strongly" reachable. Well if you work your way back up to the top of the Object hierarchy what do you find? You'll find a Thread object.

You can start a Thread and release any strong references to it and as long as it is running it will not be garbage collected. This makes sense as you don't want a running thread to disappear on you even if you don't keep strong references. (Cas: In a running state this makes it different than any other Object.)  Once a Thread is done and there are no strong references it is collected as normal.

What doesn't make sense to me is a Thread that is no longer strongly reachable and hasn't been start()ed isn't collected. Below is a program  that demonstrates this. My only explination is that an un-start()ed Thread is considered to be the root of an object hierarchy and thus not collectable. To me Cas is right that un-start()ed Thread objects should be collected as normal because if they are not referenced then there is no way for the start() method to be called.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
class Go {
    public static void main(String[] args) {
        int count = 0;

        while (true) {
            count++;
            Thread t = new Thread();
            // t.start(); // Uncomment and it will never run out of memory

            if (count == 10000) {
                System.gc();
                System.out.println("Free Memory: "
                                   + Runtime.getRuntime().freeMemory());
                count = 0;
            }

            Thread.yield();
        }
    }
}


Personally I'm not sure if this is a bug but I'm not convinced it's not a bug either. I'd really like a link to an explaintaion or one of the Sun guys to comment on this.
Offline sma

Junior Duke





« Reply #29 - Posted 2003-01-10 08:25:35 »

Quote

I have never found Swing and AWT widgets all that exciting either.


I was joking. I agree, AWT doesn't look exciting, especially not on Linux. With Swing however, one can easily create custom looks which could look nice and exciting.

Quote

Are you using SWT for Motif or GTK?  [...] I think the Motif side of SWT will become deprecated some day though.  Sad


I was referring to SWT for GTK+ 2.0.  The Motif version might be faster (I think, you could also replace Motif with Lesstif but don't know which one is faster) but the Motif look out of the box is ugly.  I don't think, SWT for Motif will die soon, the Solaris and especially the AIX version of Eclipse depends on it.

Stefan

.: Truth Until Paradox!
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (49 views)
2014-10-17 03:59:02

Norakomi (38 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (34 views)
2014-10-15 16:18:58

TehJavaDev (65 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!