Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (552)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Performance Tuning / Re: problem with currentTimeMillis() on: 2005-05-25 16:25:27
HotSpot just passes the given time through to through to the OS.  Nothing magical about 10msec, 15.6msec or any other number, at least not to HotSpot.

Before you can trust any such timing thing to be reliable you gotta run it "under load" - get a bunch of other threads running doing variable amounts of work+sleep (your AI wakes up, works for a quanta, sleeps, you decide to background load some music for the next scene, etc).  All those other threads running around will also mess with your timer's response.


2  Game Development / Performance Tuning / Re: future jni optimisations on: 2005-05-05 14:03:28
Quote
System.loadLibrary("someLibrary");
private native void someCall();

Right, so - there's absolutely no reasonable reason not to allow super easy native library integration as I described above? ie. direct integration with an *existing*, non-JNI dll.


Right - you just did it.  Since this call has no arguments, the wrapper is fairly cheap (please ignore imperfect use of CAS registers, been awhile since I looked at X86 CAS):

SUB SP,xx # push a frame, must have one for GC stack crawls
MOV EAX,FS:[18] # idiot sequence to get TLS
MOV [EAX+xx],0xpcbits # store the return-pc in TLS
# no fence needed for most PC's; memory model too strong
MOV [EAX+yy],ESP # store the sp nearby, allow GC
CALL native  # do the native call
MOV EBX,FS:[18] # idiot sequence to get TLS
MOV EAX,ESP # Find old SP if no GC in progress
CMPXCHG [EBX+yy],0 # Slap down a NULL if re-entering Java code
JNE  go_block_GC_in_progress
ADD SP,xx # pop frame
RET


You want less code than that?  Then you have a tall order on your hands - you want the JVM to have intimate knowledge of some random entry point.  To  "Trust Me - it won't block and I'll put the PC here" - which bitter experience tells me is foolish.

I've debugged any number of JVM "bugs" which were bugs in 3rd party native code caused by the 3rd-party vendor not understanding the invariants used by the JVM.  JNI goes a long way to making native code safe for the JVM.


3  Game Development / Performance Tuning / Re: future jni optimisations on: 2005-05-04 23:40:48
Quote
Yes I can tell you the grotty details if you like....
Those are the ones i prefer, so please, yes.


Ahhh.. it's a big story.  I'll make shortcuts.  You can ask for more details.  

Background: it's a desktop or server environment, so pre-emptive multi-threaded is normal, not cooperative scheduling.  Blocking native I/O.  Precise & moving GC (conservative non-moving GC allows for faster JNI calls).   Many of these steps do not apply in an embedded system, or one with cooperative suspension, or single-threaded applications, or single CPU or the native compiler is known & trusted, or the native call promises not to block (or at least statically known to block or not) etc...

Since a native call might block or otherwise take a long time, and since other threads are running and allocating, a GC must be allowed while the thread is in native code.  A moving GC makes the mutators more efficient - but there's no way to find & move the pointers in held by the native code/compiler.  So you don't hand out any raw heap pointers, you hand out Handles.  The native code is never allowed touch a heap pointer lest an ill-timed GC move things the native code is also touching, crashing the native code.  Upon return from the native code a GC *may* be in progress.  The regular Java code threads have been stopped for the GC, but the threads in native code have not  - so they have to do a lock-like thing to assure that a GC is not in progress (or doesn't start up).  Basically, you must CAS on exit from the native or you have a race condition where a GC might think all Java threads have been stopped & start moving objects, and a thread returning from a native (where GC is ok) into Java code (where GC is not) starts touching objects.  

Also, you have to be able to find all the objects - including those passed as arguments on the stack and Handlized.  Generally this is done by maintaining a mapping between PC's and which registers hold oops - but HotSpot doesn't know where the native compiler will put the JNI call's PC.  So we need the return PC (return from the native code back into the wrapper code) jammed down before we act "as if" we're in native code and allow a GC.  Same for the stack pointer.  

Finally, argument calling conventions between JIT'd code and native code are usually different - the JIT doesn't need var-args support, or legacy calling-convention support, or a JNIEnv.  Putting it together we get:

push a frame
store any objects passed in registers down (prior to handlizing)
if a sync method, lock
make a copy of the arguments:
 add the JNIEnv argument
 copy the rest from JIT convention to native convention (generally reg-reg moves on a RISC, stack-stack moves on X86)
 wrap a handle around objects (requires a null-test/branch)
store the return-pc somewhere (generally thread-local storage)
maybe memory fence, in case GC is somewhat concurrent
store the sp nearby  - which also allows a GC, and requires the objects & PC be coherent in memory
do the native call
reclaim the GC lock (generally a CAS) or block
if sync, unlock
if returning object, de-handlize
pop frame
return


Clear as mud, I hope?

4  Game Development / Performance Tuning / Re: future jni optimisations on: 2005-05-04 02:33:41
Quote
Anyone has any insight on how hotspot now handles jni calls  and if that is going to change in any direction (faster calls being the best direction, of course)


Yes I can tell you the grotty details if you like.
JNI calls are not going to get faster any time soon.

They can be made fast in some *very* specific situations, such as in embedded single-cpu devices with fixed application sets.  Or if you can match the native compiler's IR and the Java JIT's IR (an extremely tough thing to do; IBM could do it; Microsoft is trying to do it with .Net, not many other instutions can even try).
5  Game Development / Performance Tuning / Re: Does try-catch significanlt influences game sp on: 2005-04-28 14:39:06

Quote
Judging by you two arguing, can I conclude that it's the creation of the exception which is the slowest part?


Yup.

And also using pre-cooked exceptions as control flow is much slower than any other reasonable solution (such as checking return values for a special error code).  Under very restricted circumstances the server compiler will manage to make such control flow close in speed to the obvious test&branch, normally you should expect that throwing & catching a pre-cooked exception to be at least 10x slower than simply testing a return condition.

Declaring a try block and not throwing is free (nearly) so it doesn't cost to be robust and catch exceptions that are rarely thrown.
6  Game Development / Performance Tuning / Re: -XX:+PrintCompilation - What's a zombie? on: 2005-04-28 14:33:15
Zombie methods are methods whose code has been made invalid by class loading.  Generally the server compiler makes aggressive inlining decisions of non-final methods.  As long as the inlined method is never overridden the code is correct.  When a subclass is loaded and the method overridden, the compiled code is broken for all future calls to it.  The code gets declared "not entrant" (no future callers to the broken code), but sometimes existing callers can keep using the code.  In the case of inlining, that's not good enough; existing callers' stack frames are "deoptimized" when they return to the code from nested calls (or just if they are running in the code).  When no more stack frames hold PC's into the broken code it's declared a "zombie" - ready for removal once the GC gets around to it.
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (23 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (41 views)
2014-08-06 19:49:38
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!