Method Inlining in HotSpot VM

Hello Folks,
in the recent past I read a lot of posts and papers about method inlining in the HotSpot VM (especially method inlinings based on invocations via invokevirtual). From what I read the JVM is able to inline even such methods when there is only one class which implements the referred interface (since there is only one possibility for the dynamic type of the interface reference). These information might be true. But I want to see it with my own eyes. Is there any JVM option which makes it easy to profile when a method is inlined at runtime? I found that the option -XX:+PrintInlining would be the one I have to use. But when I try to enable this option while starting the JVM in debug mode the following error occurs: "Unrecognized VM option ''+PrintInlining".
Does anybody know what is going wrong? The version of my JVM is 1.6 (which should support this option).
I'm also interested in any information (preferred scientific papers) about method inlining in the HotSpot JVM.
Thank you very much...

Sorry...instead of invokevirtual I meant INVOKEINTERFACE.
Is there noone who has some hints for me?

Similar Messages

Interface method inlining

hi
I'm not sure, if this is the right forum to post to. Please move this thread to the correct one, if it is not.
Here is my question:
I want to write an "OpenGL wrapper-wrapper", that allows an abstract access to JOGL, LWJGL, etc. (for now only the two). This is only possible through an interface. In an OpenGL application there are many, many small calls to many OpenGL commands. So, if these methods are not inlined, the whole wrapper-wrapper doesn't make much sense.
I could not find any clear documentation about it. Are such methods inlined by the JIT compiler? I'm using Java 1.5 and 1.6. I know, this question cannot be answered generally. But all these methods will look similar to these ones:
Interface:
public void glDoSomething(int foo, FloatBuffer bar);
public void glDoSomethingElse(int foo);
public void glEnable(int state);
public void glDisable(int state);(e.g.) JOGL implementaion
public void glDoSomething(int foo, FloatBuffer bar)
     // invoke the JOGL method in this implementation
    gl.glDoSomething( foo, bar );
public void glDoSomethingElse(int foo)
     // invoke the JOGL method in this implementation
    gl.glDoSomethingElse( foo );
public void glEnable(int state)
     // invoke the JOGL method in this implementation
    if (!gl_states[ state ] )
        gl.glEnable( gl_const_map[ state ] );
        gl_states[ state ] = true;
public void glDisable(int state)
    if (gl_states[ state ] )
         // invoke the JOGL method in this implementation
        gl.glDisable( gl_const_map[ state ] );
        gl_states[ state ] = false;
}Would this be inlined by Java 1.5 and/or Java 1.6? Is there any good documentation about this problematic? Is there any way to ask the VM about it?
Any help is very appreciated.
Marvin

Well, the JIT compiler only inlines actual code. So you can't tell from an
interface definition whether it will decide to inline an implementation of a
method or not.Well, that's exactly, what my initial question was aiming at. I do know, that the implementing method is simple enough to be inlined. I just wanted to know, if the JIT compiler is even able to inline such code, that just implementes an interface. Is there any clear documentation about it?
No, you're right. Why would the fact that interesting or annoying questions get replies lead you to think otherwise? The volunteers here answer whatever questions they feel like answering. If nobody finds yours interesting enough or konws enough about it to answer it, it may go untouched. Or maybe the handful of people who would be interested/qualified just didn't see it before others' questions came in and pushed it down the list. If you don't get an answer after several hours or a day, a polite bump just to push it back to the forefront is fine. Just don't get too impatient or people will start getting irritated and be more inclined to flame your for your bad manners than to help you.
I'm very sorry, if I said anthing offending. Sometimes I do, even if I didn't want to. I was just wondering, if this forum actually makes sense in this way, if too few people are here, who answer questions. Believe me, when I say, that I do know, that it is (or can be) a hard job to keep track of all requests in a forum or even in a complete board. I will always be greatful for anybody, who takes up this work.
But I am convinced, that my question is an interesting one not only for me. So I was wondering, how such a forum could ever fullfill its role, if quesions like this get flooded down to page 10 in such a short time. Many questions will stay unanswered, if they would need to be recognized in minutes to not get flooded on pages, where noone will ever look again for them.
And further belive me, that this is not to be offending in any way. I just wanted to explain, why I was so shocked, that I wrote something like the above. Sorry, if this was misunderstandable.
I could be wrong but I believe this already exists.I would be highly interested, if you could point me to where it already exists.
Thanks.
Marvin

A way to avoid method inlining by JIT?

I've got a bit of code that relies on the accuracy of the stacktrace for a given call. When that code gets inlined by the JIT compiler (and thus the stacktrace altered), the behavior is no longer what I want because the class that called the method does not show up in the stack. For example:
class A {
main()
fooA();
public fooA()
fooB();
class B {
public fooB()
fooC();
class C {
public fooC()
getStackTrace();
// need to find out that class B called me
So in the example above, class A calls class B calls class C, and in the method fooC(), its imperative that the stacktrace show its caller as being class B. When JIT is disabled this is fine.
However, when JIT is enabled and this is seen as a hotspot, the code gets optimized and all of a sudden the stacktrace simply shows class A calling class C since the code in class B was inlined into A. Is there a way to make sure that the code in class B does not get inlined, or am I stuck with disabling JIT (which I don't want to do).
The obvious answer is to not rely on the stacktrace, but at this point in my application, that would require a major overhaul. Any ideas would be appreciated.
Thanks,
Charles.

If you're using the sun JRE, java has a '-Xint' option that forces interpreted mode. That'll stop the JIT from inlining.

Jdev 10g UIX: invoking an appmodule method inline

Hello,
I'm using ADF UIX in Jdev10g. I have a UIX table bound to a ViewObject, which works great. What I'm now trying to do is to create an extra column on this table which displays the result of a method call (from the AppModule). This method call takes some column data from the current row as parameters. (This fn can't be implemented in SQL as calculated col in the SQL query).
I know how to call this method via an event (from a FireAction), but this needs to be called every time a new row is rendered in the table.
So, is there a way to dynamically call an event while UIX renders the page, or is there a way to directly call this method?
My event hander looks something like:
<event name="calcit" source="*">
<invoke method="doIt" instance="${bindings.Calc}" type="..JUCtrlActionBinding">
<parameters>
<parameter .... value="${uix.current.Field1}"/>
</parameters>
</invoke>
</event>
Thanks for any help,
Matt

You may implement a transient attribute on the ViewObject that in it's getter performs the equivalent logic of calculating the extra attribute value based on that row's data.
Then simply bind to that attribute in a UI table binding and you should get the equivalent of 'calling a method to calculate this value'.
Note that if this value changes based on changes in dependent attributes, you also need to send appropriate change notifications for the transient attribute so that it's value is refreshed for the clients. See ADFToyStore sample on OTN on how to send change notifications.

Does hotspot inline methods ?

hotspot (in earlier versions only hotspot server) avoids dynamic binding for virtual method calls as long as there is no subclass has been loaded with overriding methods. But does it inline the method calls wherever possible at runtime?
Lets say, we have a bean Foo with a getName method.
class Foo {
private String name;
public String getName() {
return name;
Now as long as there is no subclass of Foo have been loaded hotspot will not use dynamic binding. But when a class does something like
Foo f = new Foo(); //watch that both the type and runtime type is Foo
f.getName();
Will hotspot inline the method call?
Thanks.

My understanding is that Hotspot may inline a method. I think that there is a threshold as well as other factors, such as being final, private, etc...... See:
http://developer.java.sun.com/developer/technicalArticles/Networking/HotSpot/inlining.html
"Inlining is based on a form of global analysis. Dynamic
loading significantly complicates inlining, because it
changes the global relationships in a program. A new
class may contain new methods that need to be inlined in
the appropriate places. So the Java HotSpot performance
engine must be able to dynamically deoptimize (and then
reoptimize if necessary) previously optimized hot spots,
even during the execution of the code for the hot spot.
Without this capability, general inlining cannot be safely
performed on Java technology-based programs."
from: http://java.sun.com/products/hotspot/whitepaper.html
BTW, these were the first two hits when I searched for 'inlining with hotspot' up in the top right corner. This is slightly different, but may be of interest:
http://forum.java.sun.com/thread.jsp?forum=4&thread=260074
hth,
m

Hotspot vs Classic

What is the advantage of Hotspot VM over Classic VM? Does the hotspot vm use method inlining?

Wouldn't it be easier just to tell the poor fellow that Hotspot is made by Sun. It's a trademark for some technology, that can optimize and recompile a running program based on profiling and analysing the programs behaviour (thus finding "hot spots" in the program, which are good candidates for better optimization). IBM has something similar but without the fancy name on it.
The algorithmic perspective...
It could be argued that it is not the forum. But then again: Try to look at it from an algorithmic point of view - it does not get less interesting now, does it?
The first JVMs were byte code interpreters or simulators. The technique of interpreting the code was quite slow, but a great deal easier to implement.
The next generation of JVMs were able to compile the byte code, or even start executing a program by interpreting the byte code, while it was being translated (compiled) into platform dependant machine code instructions.
HotSpot (and similar techniques) does somethin similar, but extends the technique, by being able to re-compile the byte code. During the re-compilation the optimizer may choose to use techniques like inlining methods (ie. place a copy of a method body instead of making a method call), loop-unrolling (a special technique to optimize loops by minimizing loop-termination checks), and lots of other clever stuff.
This runtime re-compilation has the potential to outrun statically compiled programs like C++ -based programs. Further more: You do not have to re-compile your programs when Sun or IBM comes up with better ways of optimizing. You simply install a new JVM, and you programs runs faster!
Did this answer your questions?
Kind regards
Kvols

View activity by clicking hotspot on ALV report

Hi,
I have a report with a ALV grid as output. This output cells represent different activities in CRM. By clicking on one cell, the hotspot gets activated and the selected activity should be opened.
How can I implement to go into the selected activity?
I already have implemented by method for the hotspot processing.
What function do I have to use to jump into the activity?
Thanks for your help!
Caroline

Hi,
1. hotspot definition.
   **Hot spot Handler
    HANDLE_HOTSPOT_CLICK FOR EVENT HOTSPOT_CLICK OF CL_GUI_ALV_GRID
                      IMPORTING E_ROW_ID E_COLUMN_ID ES_ROW_NO,
2.implementation
*Handle Hotspot Click
METHOD HANDLE_HOTSPOT_CLICK .
    CLEAR: V_ROW,V_COLUMN,V_ROW_NUM.
    V_ROW = E_ROW_ID.
    V_COLUMN = E_COLUMN_ID.
    V_ROW_NUM = ES_ROW_NO.
PERFORM HANDLE_HOTSPOT_CLICK USING E_ROW_ID E_COLUMN_ID ES_ROW_NO .
ENDMETHOD.                    "lcl_event_handler
FORM HANDLE_HOTSPOT_CLICK USING I_ROW_ID TYPE LVC_S_ROW
                                I_COLUMN_ID TYPE LVC_S_COL
                                IS_ROW_NO TYPE LVC_S_ROID.
READ TABLE IT_FINAL INDEX I_ROW_ID .
IF SY-SUBRC = 0.
    IF I_COLUMN_ID-FIELDNAME = 'VGBEL'
              AND NOT IT_FINAL-VGBEL IS INITIAL.
      PERFORM FORM_REFRESH.
      SET PARAMETER ID 'AUN' FIELD IT_FINAL-VGBEL.
      CALL TRANSACTION 'VA03' AND SKIP FIRST SCREEN.
    ENDIF.
**if user clicks on Delivery
    IF I_COLUMN_ID-FIELDNAME = 'VBELN'
            AND NOT IT_FINAL-VBELN IS INITIAL.
      PERFORM FORM_REFRESH.
      SET PARAMETER ID 'VL' FIELD IT_FINAL-VBELN.
      CALL TRANSACTION 'VL03N' AND SKIP FIRST SCREEN.
    ENDIF.
**if user clicks on Vendor Name
    IF I_COLUMN_ID-FIELDNAME = 'NAME'
             AND NOT IT_FINAL-EBELN IS INITIAL.
      PERFORM FORM_REFRESH.
      SET PARAMETER ID 'BES' FIELD IT_FINAL-EBELN.
      CALL TRANSACTION 'ME23N' AND SKIP FIRST SCREEN.
    ENDIF.
ENDIF.
ENDFORM.
you need to use set_handler for hot_spot.
regards
vijay

What exactly does "Java is an interpreted language" mean?

interpreted as opposed to what?

It means Java (like e.g. Pascal and C) can be interpreted. An interpreter reads byte code and executes its operations. Often Java is interpreted in small devices (cell phones, TV set top boxes). Back when Java first came out, the first Java environments were interpreters.
Java (like e.g. Pascal and C) can also be compiled. One popular compiler is Hotspot, which is included in the Sun JDK. Hotspot is a "dynamic compiler": it compiles often executed code while a Java program is being run, and interprets code that is executed only a few times (e.g. initialization code). In contrast to a dynamic compiler, a JIT (just-in-time) compiler doesn't include an interpreter; a JIT compiles everything. IBM, BEA and Oracle are other major Java compiler vendors.
There are also so-called "static compilers", which write the compiled code into a file. These usually produce less efficient code than JITs or dynamic compilers, because they cannot perform optimizations like non-static method inlining or using CPU version-specific instructions.
Often the claim "Java is interpreted" is a hold-over from the early days; people heard of the first interpreter and it stuck.

What is the status of fixing nio Buffer performance?

The performance of nio Buffers is very slow in comparison to primitive arrays. Does anyone know the status for getting this fixed? For performance sensitive code, Buffers are currently unacceptable.
Several Bugs were open regarding this issue, but they have all mysteriously been closed without resolution?
(Bug ID: 4411600, http://developer.java.sun.com/developer/bugParade/bugs/4411600.html)
Any insight would be appreciated.

Here are numbers using the code from the Bug reference I posted above.
(Bug ID: 4411600, http://developer.java.sun.com/developer/bugParade/bugs/4411600.html)
The only change I made was to the main() function so I could run tests multiple times to see if Hotspot would kick in at some point.
Here is the change I made. Replaced the original main() function with the following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
public static void main(String[] args) {
for ( int x = 0; x < 5; x++ )
System.gc();
System.out.println();
System.out.println( ">>>> run #" + x );
run();
public static void run()
timeArray();
time("heap", ByteBuffer.allocate(SIZE));
time("direct", ByteBuffer.allocateDirect(SIZE));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Btw, I am running this under Win2k.
The results follow.
D:\dev\parse>java -server Bench3
run #0array 30
array rev 80
heap 51
heap rev 90
direct 601
direct rev 401
run #1array 40
array rev 40
heap 571
heap rev 661
direct 671
direct rev 290
run #2array 41
array rev 40
heap 550
heap rev 671
direct 591
direct rev 291
run #3array 40
array rev 50
heap 551
heap rev 661
direct 590
direct rev 300
run #4array 50
array rev 51
heap 561
heap rev 651
direct 581
direct rev 291
D:\dev\parse>java -client Bench3
run #0array 181
array rev 190
heap 380
heap rev 390
direct 791
direct rev 701
run #1array 180
array rev 180
heap 861
heap rev 802
direct 731
direct rev 711
run #2array 180
array rev 180
heap 1202
heap rev 721
direct 721
direct rev 971
run #3array 200
array rev 180
heap 741
heap rev 731
direct 861
direct rev 821
run #4array 180
array rev 210
heap 911
heap rev 721
direct 741
direct rev 741
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
But after taking a closer look at the code I realized that both the heap and direct buffers were being run through the same sum() and reverse() methods, so maybe Hotspot's inlining policy avoids keeping more than one specialized version of a function cached?
So I re-ran the benchmark, but only running time("heap"...) and time("direct",...) one at a time. I will not bother posting the numbers, but this time array, heap, and direct were all roughly equivalent.
So depending on the scenario, maybe it is not as bad as I though?
To try another variant, I replaced all calls to bb.get(j) with bb.get(), thinking this may be an opportunity for Buffer to be faster than array, since no start-of-buffer bounds check should be necessary (can only iterate forward).
But even running heap and direct separately, the test yielded slow numbers that suggest no inlining was performed again?
So I'm not sure what to think? I would like to use Buffers over primitive arrays, but I have no certainty of the performance characteristics of Buffers? They may run fast, or they may run very slow, depending on the scenario and which functions are used.
Here are the numbers after replacing calls bb.get(j) with bb.get().
D:\dev\parse>java -server Bench3
run #0array 41
array rev 80
heap 271
heap rev 381
run #1array 40
array rev 50
heap 231
heap rev 321
run #2array 40
array rev 40
heap 241
heap rev 321
run #3array 40
array rev 50
heap 231
heap rev 321
run #4array 40
array rev 40
heap 231
heap rev 320

What are the opcodes that put vars on the local frame array? Remove them?

Does anyone know of a reference that lists all the opcodes that put a local variable in the local frame array (like ASTORE, BIPUSH, etc) and all the ones that remove them (like POP, ALOAD, etc)?

BIPUSH doesn't affect the frame, it pushes a value onto the operand stack. The distinction may be subtle, but it's
important since the JVM is a stack-based architecture (in other words, if you don't make the distinction, than your
list contains [almost] all of the JVM opcodes).You're right. So then, what exactly are POP, DUP, etc doing? Are they taking from the frame?First thing to remember is that the frame and operand stack are logically different: the frame contains method parameters and local variables, while the operand stack is used for intermediate results. They may be implemented using a single processor stack (in X86 terms, the BP register would point to the start of the frame, while pushes and pops would modify the SP), but don't have to be. I think the JVM spec even talks about storing frames in the heap.
Here's an example:
public static int foo(int a, int b)
    int c = a + b;
    int d = (c + c) * 5;
    return d;
}Running javap -c to show the bytecodes, we get this:
public static int foo(int, int);
Code:
   0:   iload_0
   1:   iload_1
   2:   iadd
   3:   istore_2
   4:   iload_2
   5:   iload_2
   6:   iadd
   7:   iconst_5
   8:   imul
   9:   istore_3
   10: iload_3
   11: ireturnThe two method parameters, a and b, are stored in the frame in slot 0 and 1 (if this were an instance method, slot 0 would contain "this"). They get pushed onto the stack using the iload opcode (the normal version of this opcode takes a second byte index into the frame; to minimize code size, the JVM has alternate versions of most frame-access opcodes that are hardcoded for a specific low-numbered slots).
After the loads, the stack will contain the values held in b and a; the iadd instruction adds these together, leaving the result on the stack. The istore_2 removes the topmost value from the operand stack, and stores it in the frame (in the slot assigned to variable "c").
To your question about dup and so forth, I was hoping to demonstrate that with the repeated reference to variable "c"; instead, the compiler translated that into the two iload operations (opcodes 4 and 5). I suppose it makes sense, but it shows just how little optimization the compiler attempts to do -- instead, it relies on Hotspot being smart enough to optimize hardware accesses.
The iconst_5 opcode is another example of something that affects the operand stack but not the frame: it pushes a hardcoded constant value onto the stack.
It's also another case where the JVM defines several opcodes that do the same thing: the iconst_n for values -1 to 5, bipush for values that are outside this range but still smaller than a byte, sipush for values that will fit into a short, and ldc for everything else. The goal is efficient code generation: 1-3 bytes for most of the integer values that you're likely to load. The ldc opcode is interesting in its own right: it does a lookup into a per-class table to find the value to push. Not very efficient in terms of CPU cycles and memory access (although it can be inlined by Hotspot), but again efficient from a bytecode perspective: if you're loading a large constant, there's at least a chance that you'll be loading it multiple times.
Chapter 6 of the VM spec lists all the opcodes, and I seem to remember groupings by purpose: http://
java.sun.com/docs/books/jvms/second_edition/html/Instructions.doc.htmlUnfortunately, it doesn't quite do that. They're mostly all in the same place on the summary page but not quite all. (For example, the array ones were in a separate place) And the link you posted lists them only alphabetically.Yeah, but jverd posted the link to section 3.11, which groups the opcodes. You probably want 3.11.2: http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#6348
Which leads to the more interesting question: why?

Compilation decision

(Context: I'm new to Java, not to development)
I would like to have my frequently-executed code in a long-running enumeration/calculation application compiled and to have methods inlined. I can't seem to achieve this except in cases that are unpredictable (to me). I am running jre 5.0.90.3 on WinXP, with switches -server -XX:MaxInlineSize=999999 -XX:FreqInlineSize=999999 -XX:CompileThreshold=1000 -XX:+PrintCompilation.
Some methods are executed hundreds of millions of times and not mentioned by PrintCompilation. By stumbling around in the dark I have formed a theory that method size is a compilation criterion. I don't understand the relationship between compilation and inlining, e.g., can a compiled method be inlined into another compiled method? I would love to see pseudocode for the jvm's compilation decision. In case it would help: assume final/static methods.
Much more generally, I lack understanding of why comprehensive compilation of large portions of my code is not (as far as I know) an option. In the case of this application and subsequent ones in the endeavor (akin to scientific research) it would be perfectly acceptable to have the jvm spend "a lot" of time at the start of a run doing compilation.
All enlightenment appreciated!

I assume that you are working with the HotSpot server VM.
Up front, I should say that +PrintCompilation does not indicate which methods have been inlined, only the methods that are the root of the compilation. (There are ways in debug VMs to print inlining decisions.)
The inlining algorithm in the server VM is complicated, and the VM could profit from some simplification in this area.
There is an overriding size limit on methods that can get compiled. In 5.0, methods larger than 8000 bytes (of bytecode) are not considered for compilation.
Method size is not a compilation criterion, but it is an inlining criteria. To avoid bloat in the CodeCache, the VM will shy away from inlining larger methods. You apparently have discovered this, as you experimented using the MaxInlineSize and FreqInlineSize knobs. Furthermore, if the called method is already compiled, it may still be inlined into the caller, but it is subject to an additional test against the size of the generated code. Additionally, there are rules for accessor methods to allow them to be inlined nearly always. You can look at byecodeInfo.cpp in the HotSpot source to get a more detailed sense of the inline decision making.
In the other direction, inlining should not prevent compilation, but could delay it. Compilation is triggered on the number of times a method is invoked in the interpreter. If a method is inlined at a hot call site, the rate of interpreter invocations will obviously decrease, delaying standalone compilation of the method .
As observed with the reference to final/static methods, direct inlining can only occur when the called method is known. In some cases, inlining can occur at virtual call sites, but only when there is a single implementor or when a runtime class check is incorporated into the generated code.
As an aside, -Xcomp is not a good choice as a rule of thumb. This option causes some methods to be compiled prematurely, that is, before referenced classes are loaded. For the server compiler, profiling data is non-existent, and the VM may deoptimize/recompile a method several times before getting a "optimal" compile.
Hope this helps.

[Not really solved] Video with Pidgin is not working

Hi,
I would like to use video chat with Pidgin, but it doesn't work on my computer.
I have a webcam (:D), and it seems that it is correctly recognized because ` vlc v4l2:// ' shows me my face. I'm using XMPP (with a GMail account, but this shouldn't matter) and want to chat with someone using Ubuntu and Pidgin 2.6.6 (she has a webcam which seems to work correctly)
In the "Voice/Video settings" plugin, there are three options in the field Video → Input → Plugins : "default", "Test Input" and "Video4Linux" (and only "default" in the field Device, for the three plugins)
"default" and "Video4Linux" give
(21:03:34) Error with your webcam
(21:03:34) Conference error
(21:03:34) The call has been terminated.
as soon as I try to start a video call, and "Test Input" only shows me a test pattern (but I guess this is the meaning of "Test Input" )
BTW, I wonder why there is only "Video4Linux" and not "Video4Linux2"
The Pidgin's FAQ says this
How do I configure my microphone/webcam?
Currently, the command-line gstreamer-properties program is used. This is only available on GNOME-based systems. On other systems, Pidgin makes its best guess as to which device to use. A plugin is planned to support this functionality on other systems.
But I don't use GNOME, my desktop environment is LXDE.
What could I do to make my webcam work with Pidgin?
Thank you!
Edit:
- my system is up to date
- I have farsight2 and gstreamer0.10-{good,bad,ugly} installed
Fractal
Last edited by Fractal (2010-06-13 15:50:01)

Well, the problem is not really solved actually.
Pidgin recognizes my webcam but I still cannot open a video chat.
When I try to start a video chat, the following errors are displayed in the debug window :
(17:38:41) mediamanager: gst pipeline error: Could not encode stream.
(17:38:41) mediamanager: Debug details: gstx264enc.c(737): gst_x264_enc_header_buf (): /GstPipeline:pipeline0/GstBin:conf_0x306c000/FsRtpConference:fsrtpconference1/GstBin:discover_1_97/GstX264Enc:x264enc0:
Unexpected x264 header.
When the other person tries to call me, I have something like that :
(17:43:23) jingle-rtp: received codec: 32: video MPV clock:90000 channels:0
(17:43:23) jingle-rtp: received codec: 26: video JPEG clock:90000 channels:0
(17:43:23) jingle-rtp: received codec: 97: video H263-1998 clock:90000 channels:0
(17:43:23) jingle-rtp: received codec: 34: video H263 clock:90000 channels:0
(17:43:23) jingle-rtp: received codec: 98: video DV clock:90000 channels:0
(17:43:23) jabber: setting param stun-ip for stream using auto-discovered IP: 209.85.229.126
(17:43:23) jabber: setting param stun-port for stream using auto-discovered port: 19302
(17:43:23) mediamanager: Couldn't read fs-element.conf: No such file or directory
(17:43:23) backend-fs2: Couldn't read fs-codec.conf: No such file or directory
(17:43:23) backend-fs2: Creating hash table for sessions
(17:43:23) backend-fs2: connecting pad: success
(17:43:23) backend-fs2: Creating hash table for participants
(17:43:23) media: Creating hash table for sessions
(17:43:23) gtkmedia: state: 0 sid: video-session name: (null)
(17:43:23) jingle-rtp: state-changed: state 0 id: video-session name: (null)
(17:43:23) backend-fs2: got new local candidate: 1
(17:43:23) backend-fs2: got new local candidate: 1
(17:43:23) backend-fs2: farsight-component-state-changed: component: 1 state: GATHERING
(17:43:23) backend-fs2: farsight-component-state-changed: component: 2 state: GATHERING
(17:43:23) jingle-rtp: jingle_rtp_codecs_changed_cb: session_id: video-session jingle_session: 0x212b6a0
(17:43:23) jingle-rtp: jingle_rtp_candidates_prepared_cb
(17:43:23) jingle: jingle_iceudp_finalize
(17:43:23) jingle: jingle_transport_finalize
(17:43:26) backend-fs2: farsight-send-codec-changed: codec: 96: video THEORA clock:90000 channels:0 delivery-method=inline
(17:43:27) jingle-rtp: stream-info: type 1 id: video-session name: (null)
(17:43:27) jingle-rtp: stream-info: type 1 id: (null) name: (null)
(17:43:27) backend-fs2: farsight-component-state-changed: component: 1 state: CONNECTING
(17:43:27) backend-fs2: farsight-component-state-changed: component: 2 state: CONNECTING
(17:43:36) backend-fs2: farsight-component-state-changed: component: 1 state: FAILED
(17:43:36) backend-fs2: farsight-error: 108: Could not establish connection
(17:43:36) backend-fs2: farsight-component-state-changed: component: 2 state: FAILED
It seems that my Pidgin want to encode the flux in H264 and the other wants Theora
Fractal

Is the instance fields have private accessibility in String class?

Is the instance fields have private accessibility in an immutable class, such as the String class?
also Could any one answer the following question,
(This is the question I got in written exam for job recruitment)
"Invoking a method can represent a significant amount of overhead in a program; as such, some compilers will perform an optimization called "method inlining." This optimization will remove a method call by copying the code inside the method into the calling method."
Referring to the text above, which one of these statements is true?
Choice 1 The performance benefits should be balanced against the increased chance of a RuntimeException.
Choice 2 It allows the use of getter and setter methods to execute nearly as fast as direct access to member variables.
Choice 3 This optimization will only occur if the relevant methods are declared volatile.
Choice 4 The developer of inlined methods must copy and paste the code that is to be inlined into another method.
Choice 5 It prevents code from executing in a way that follows object-oriented encapsulation.

Sarwan_Gres wrote:
Is the instance fields have private accessibility in an immutable class, such as the String class?Usually, but not always.
"Invoking a method can represent a significant amount of overhead in a program; as such, some compilers will perform an optimization called "method inlining." This optimization will remove a method call by copying the code inside the method into the calling method."The java compiler does not inline methods so this is not relevant to Java. (The JVM does inline methods) The java compiler does inline constants known at compile time but it is a feature causes more trouble than good IMHO.

1.2.2 javac -O question

The following URL http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/javac.html#options
states ...
-O
Note: the -O option does nothing in the current implementation of javac.
What does this mean ... If I use -O nothing happens? Does this mean that there is no support for in-lining anymore?
thanks
mark

Sorry I should have been more explicit.
In 1.1.8 -O use to inline final methods. Are final methods inlined in javac 1.2.2? If yes then how is this accomplished given that -O in javac 1.2.2 has no effect. If no then is there a reason why Sun chose not to inline methods anymore?
thanks
mark

ALV Grid event handlers

Hello Friends;
I have a problem with event handlers. I have defined events for double_click, data_change and hotspot_click. At first run of the program everything runs fine but when I make a change at the screen (like pressing Enter or entering a value at a screen field) the handlers seem to be called a couple of times. For example at a hotspot click I call an accounting document display and when I want to return with back button the program seems to be stuck at document display. Actually it calls event handler over and over again. How can I solve this problem? Can refreshing grid be a solution?
Thx in advance
Ali

Hello Ali
The problem is that after handling the hotspot event the current cell is still on the field with the hotspot. Thus, when you push ENTER the ALV grid checks the current cell which has a hotspot defined which, in turn, raises event HOTSPOT_CLICK.
Therefore, you have to move the current cell to another cell that has no hotspot defined. Have a look at the implementation of the event handler method. The hotspot is on field KUNNR. After calling transaction XD03 I shift the current cell to field BUKRS.
If you comment these lines you will see the same behaviour of the report as you described.
*& Report ZUS_SDN_TWO_ALV_GRIDS
REPORT ZUS_SDN_ALVGRID_EVENTS.
DATA:
gd_okcode        TYPE ui_func,
gt_fcat          TYPE lvc_t_fcat,
go_docking       TYPE REF TO cl_gui_docking_container,
go_grid1         TYPE REF TO cl_gui_alv_grid.
DATA:
gt_knb1          TYPE STANDARD TABLE OF knb1.
PARAMETERS:
p_bukrs      TYPE bukrs DEFAULT '1000' OBLIGATORY.
*       CLASS lcl_eventhandler DEFINITION
CLASS lcl_eventhandler DEFINITION.
PUBLIC SECTION.
    CLASS-METHODS:
      handle_hotspot_click FOR EVENT hotspot_click OF cl_gui_alv_grid
        IMPORTING
          e_row_id
          e_column_id
          es_row_no
          sender.
ENDCLASS.                    "lcl_eventhandler DEFINITION
*       CLASS lcl_eventhandler IMPLEMENTATION
CLASS lcl_eventhandler IMPLEMENTATION.
METHOD handle_hotspot_click.
*   define local data
    DATA:
      ls_knb1     TYPE knb1,
      ls_col_id   type lvc_s_col.
    READ TABLE gt_knb1 INTO ls_knb1 INDEX e_row_id-index.
    CHECK ( ls_knb1-kunnr IS NOT INITIAL ).
    SET PARAMETER ID 'KUN' FIELD ls_knb1-kunnr.
    SET PARAMETER ID 'BUK' FIELD ls_knb1-bukrs.
    CALL TRANSACTION 'XD03' AND SKIP FIRST SCREEN.
*   Set active cell to field BUKRS otherwise the focus is still on
*   field KUNNR which will always raise event HOTSPOT_CLICK
    ls_col_id-fieldname = 'BUKRS'.
    CALL METHOD go_grid1->set_current_cell_via_id
      EXPORTING
        IS_ROW_ID    = e_row_id
        IS_COLUMN_ID = ls_col_id.
ENDMETHOD.                    "handle_hotspot_click
ENDCLASS.                    "lcl_eventhandler IMPLEMENTATION
START-OF-SELECTION.
SELECT        * FROM knb1 INTO TABLE gt_knb1
         WHERE bukrs = p_bukrs.
* Create docking container
CREATE OBJECT go_docking
    EXPORTING
      parent                      = cl_gui_container=>screen0
      ratio                       = 90
    EXCEPTIONS
      OTHERS                      = 6.
IF sy-subrc <> 0.
*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*              WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
* Create ALV grid
CREATE OBJECT go_grid1
    EXPORTING
      i_parent          = go_docking
    EXCEPTIONS
      OTHERS            = 5.
IF sy-subrc <> 0.
*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*              WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
* Set event handler
SET HANDLER:
    lcl_eventhandler=>handle_hotspot_click FOR go_grid1.
* Build fieldcatalog and set hotspot for field KUNNR
PERFORM build_fieldcatalog_knb1.
* Display data
CALL METHOD go_grid1->set_table_for_first_display
    CHANGING
      it_outtab       = gt_knb1
      it_fieldcatalog = gt_fcat
    EXCEPTIONS
      OTHERS          = 4.
IF sy-subrc <> 0.
*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*              WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
* Link the docking container to the target dynpro
CALL METHOD go_docking->link
    EXPORTING
      repid                       = syst-repid
      dynnr                       = '0100'
*      CONTAINER                   =
    EXCEPTIONS
      OTHERS                      = 4.
IF sy-subrc <> 0.
*   MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*              WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
* ok-code field = GD_OKCODE
CALL SCREEN '0100'.
END-OF-SELECTION.
*&      Module STATUS_0100 OUTPUT
*       text
MODULE status_0100 OUTPUT.
SET PF-STATUS 'STATUS_0100'.
* SET TITLEBAR 'xxx'.
ENDMODULE.                 " STATUS_0100 OUTPUT
*&      Module USER_COMMAND_0100 INPUT
*       text
MODULE user_command_0100 INPUT.
CASE gd_okcode.
    WHEN 'BACK' OR
         'END' OR
         'CANC'.
      SET SCREEN 0. LEAVE SCREEN.
    WHEN OTHERS.
ENDCASE.
CLEAR: gd_okcode.
ENDMODULE.                 " USER_COMMAND_0100 INPUT
*&      Form BUILD_FIELDCATALOG_KNB1
*       text
* --> p1        text
* <-- p2        text
FORM build_fieldcatalog_knb1 .
* define local data
DATA:
    ls_fcat        TYPE lvc_s_fcat.
CALL FUNCTION 'LVC_FIELDCATALOG_MERGE'
    EXPORTING
*     I_BUFFER_ACTIVE              =
      i_structure_name             = 'KNB1'
*     I_CLIENT_NEVER_DISPLAY       = 'X'
*     I_BYPASSING_BUFFER           =
*     I_INTERNAL_TABNAME           =
    CHANGING
      ct_fieldcat                  = gt_fcat
    EXCEPTIONS
      inconsistent_interface       = 1
      program_error                = 2
      OTHERS                       = 3.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
READ TABLE gt_fcat INTO ls_fcat
       WITH KEY fieldname = 'KUNNR'.
IF ( syst-subrc = 0 ).
    ls_fcat-hotspot = abap_true.
    MODIFY gt_fcat FROM ls_fcat INDEX syst-tabix.
ENDIF.
ENDFORM.                    " BUILD_FIELDCATALOG_KNB1
Regards
Uwe

Method Inlining in HotSpot VM

Similar Messages

Maybe you are looking for