Execution jvm commands from java

[shaposhnik]

Hi all

is it possible to execute JVM commands as part of java code ?
the reason behind this, is that i am trying to use the goto command,
only it seems like it is supported by the JVM, so i thought it would be
possible to bypass it this way, using directly the jvm goto command.

thanks in advance,
Yaron Shaposhnik.

 

[shaposhnik]

shaposhnik כתב:

Hi all

is it possible to execute JVM commands as part of java code ?
the reason behind this, is that i am trying to use the goto command,
only it seems like it is NOT supported by the JVM, so i thought it would be
possible to bypass it this way, using directly the jvm goto command.

thanks in advance,
Yaron Shaposhnik.

its not supported by the JVM..

 

[Paul Davis]

Hi all

is it possible to execute JVM commands as part of java code ?
the reason behind this, is that i am trying to use the goto command,
only it seems like it is supported by the JVM, so i thought it would be
possible to bypass it this way, using directly the jvm goto command.

thanks in advance,
Yaron Shaposhnik.

Sounds like you are trying to do the equivalent of assembly macros in
C.
You might want to take a look at the Byte Code Engineering Library
(BCEL)
jakarta.apache.org/bcel/

 

[Patricia Shanahan]

shaposhnik כתב:

its not supported by the JVM..

Now I'm confused. Goto is supported by the JVM, it is opcode 167. There
is no goto, except as a keyword, in Java.

I don't know of any way of accessing JVM commands from Java. You might
be able to do something really nasty with post-processing of the class
file, but it would be tricky. Branching is relative, so if you inserted
a command you might need to adjust other branches.

As a matter of curiosity, why use goto?

Patricia

 

[shaposhnik]

Patricia Shanahan כתב:

Now I'm confused. Goto is supported by the JVM, it is opcode 167. There
is no goto, except as a keyword, in Java.

I don't know of any way of accessing JVM commands from Java. You might
be able to do something really nasty with post-processing of the class
file, but it would be tricky. Branching is relative, so if you inserted
a command you might need to adjust other branches.

As a matter of curiosity, why use goto?

Patricia

hi
thanks for the response. i am trying to implement a state machine.
currently it is working as a while loop with a switch and many cases on
the state number, and a break after every case. i was hoping to speed
it up by using goto's.

 

[shaposhnik]

Paul Davis כתב:

Sounds like you are trying to do the equivalent of assembly macros in
C.
You might want to take a look at the Byte Code Engineering Library
(BCEL)
jakarta.apache.org/bcel/

thanks. ill check it out

 

[Oliver Wong]

i am trying to implement a state machine.
currently it is working as a while loop with a switch and many cases on
the state number, and a break after every case. i was hoping to speed
it up by using goto's.

Do you realize that switch, break, and while loops all compile to goto
and conditional jump statements at the bytecode level anyway?

- Oliver

 

[Patricia Shanahan]

Do you realize that switch, break, and while loops all compile to
goto and conditional jump statements at the bytecode level anyway?

- Oliver

However, you don't need the equivalent of switch, at least in the same
sense, to implement a goto-based state machine. The code for a single
state looks something like:

state_20:
do something;
if(some condition)
goto state_30;
else
goto state_21;

Patricia

 

[Patricia Shanahan]

However, you don't need the equivalent of switch, at least in the same
sense, to implement a goto-based state machine. The code for a single
state looks something like:

state_20:
do something;
if(some condition)
goto state_30;
else
goto state_21;

A State interface would probably be the most similar Java approach to this:

interface State{
State nextState([some parameters]);
}

with lots of references to subclass instances:

State someStateName = new State(){
State nextState([some parameters]){
do something;
if(some condition)
return someOtherState;
else
return yetAnotherState;
}
};

With a driving loop of the form:

State state = startState;
while(state != endState){
state = state.nextState(some parameters);
}

However, for a large monolithic state machine, this would end up with
hundreds of anonymous inner class files, one for each state.

Patricia

 

[Chris Uppal]

A State interface would probably be the most similar Java approach to
this:

But /horrendously/ inefficient if the per-state processing is small but
frequent, as it would be in text parsing, for instance.

/If/ such considerations were relevant, then I'd just stick to the
loop-around-a-switch approach myself. I might do that anyway, even if speed
weren't a concern, if I felt that putting the logic for each case into a
separate class made the code less clear than it might be.

-- chris

 

[Chris Uppal]

Do you realize that switch, break, and while loops all compile to goto
and conditional jump statements at the bytecode level anyway?

There are both tableswitch and lookupswitch operations defined at the bytecode
level. The former is probably JITed into a jump-table. The latter is more
complex, but is clearly designed to allow more efficient code than just a
sequence of compare-and-branch operations -- either a binary chop, or maybe a
hashtable lookup.

-- chris

 

[Paul Davis]

Do you realize that switch, break, and while loops all compile to goto
and conditional jump statements at the bytecode level anyway?

javap is your friend

 

[shaposhnik]

Oliver Wong כתב:

Do you realize that switch, break, and while loops all compile to goto
and conditional jump statements at the bytecode level anyway?

- Oliver

how can i be sure that the cases are translated to goto's and not to
many if-else commands ?

 

[shaposhnik]

Patricia Shanahan כתב:

Patricia Shanahan wrote:
A State interface would probably be the most similar Java approach to this:

interface State{
State nextState([some parameters]);
}

with lots of references to subclass instances:

State someStateName = new State(){
State nextState([some parameters]){
do something;
if(some condition)
return someOtherState;
else
return yetAnotherState;
}
};

With a driving loop of the form:

State state = startState;
while(state != endState){
state = state.nextState(some parameters);
}

However, for a large monolithic state machine, this would end up with
hundreds of anonymous inner class files, one for each state.

Patricia

my top priority is speed, only than comes elegance. i fear that many
classes could result in excessive overhead.

 

[Chris Uppal]

how can i be sure that the cases are translated to goto's and not to
many if-else commands ?

There's no reason why they should be compiled into anything other than
bytecode-level "case statements" -- that would just be the compiler (javac)
making extra work for itself to no purpose. However, if you feel strongly
about the matter then you can use the javap tool (comes with the SDK) to
disassemble the classfile.

But that won't tell you what the JITer is doing when it creates real executable
code from the bytecode. If that bothers you then you /can/ extract the
information (using JVMTI plus a disassembler for your target hardware), but I
doubt if it's worth the effort -- it's not a pre-packaged operation, you'd have
to code it yourself.

It's not something you can change so why worry ? In any case, if you don't
/already/ have detailed, and correctly obtained, performance figures
(comparing -client and -server, taking proper account of the JIT warm-up time,
etc, etc), then you clearly don't care enough about the performance of this
code to worry about what the JIT is doing.

-- chris

 

[Paul Davis]

how can i be sure that the cases are translated to goto's and not to

many if-else commands ?

Just disassemble the byte code.
In your JDK bin directory there is a program called "javap" you can use
it to dissassemble the byte code and see what the compiler is
generating.
javap -help will give you the options.

There's no need to argue about what the compiler is doing when every
JDK comes with the ability to disassemble the code.

 

[Patricia Shanahan]

Patricia Shanahan כתב:

Patricia Shanahan wrote:
A State interface would probably be the most similar Java approach to this:

interface State{
State nextState([some parameters]);
}

with lots of references to subclass instances:

State someStateName = new State(){
State nextState([some parameters]){
do something;
if(some condition)
return someOtherState;
else
return yetAnotherState;
}
};

With a driving loop of the form:

State state = startState;
while(state != endState){
state = state.nextState(some parameters);
}

However, for a large monolithic state machine, this would end up with
hundreds of anonymous inner class files, one for each state.

Patricia

my top priority is speed, only than comes elegance. i fear that many
classes could result in excessive overhead.

Switches may be your best choice.

The concern I have with the single state machine and large switch is
that it leads to a pointer based indirect branch, for dense case
numbers, or a series of conditional branches with no particularly strong
take/not-take pattern, for the sparse case numbers.

The cost of a switch will depend on how well the processor's branch
prediction logic handles the patterns your loop produces. At the worst,
it could be loading the wrong stuff in the pipeline almost every
iteration, costing a cycle for each pipeline stage when it finds out
what the branch really did.

There is some hope that decomposing the problem into a series of smaller
switches would improve predictability for each conditional branch.

Patricia

 

[Chris Uppal]

The concern I have with the single state machine and large switch is
that it leads to a pointer based indirect branch, for dense case
numbers, or a series of conditional branches with no particularly strong
take/not-take pattern, for the sparse case numbers.

You could say that this goes with the teritory -- you are going to take a
branch misprediction penalty on most every state change no matter how the state
machine is implemented. It's a property of the algorithm (or "technique" if
you prefer) rather than the specific code structures used to express it.

The only way to avoid it is to use a different expression of the problem --
i.e. not to use a state-machine in the first place. For instance collapsing
(nearly) always taken sequences of states into single passages of (usually)
jump-free code. Not something I'd want to do by hand... (Might be fun to
program, though ;-)

-- chris

 

[Paul Davis]

Seems like the thing to do is simply create both versions (since speed
appears to the the most critical issue) and run it with the -Xprof
option to get better detail of what the cpu usage it.