• Post Reply Bookmark Topic Watch Topic
  • New Topic

Dummy bytecode  RSS feed

 
david colais
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi guys...
Can anyone explain what a dummy bytecode is in java and its pupose of existence???
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know, but this is too difficult for "beginning" so I shall move this discussion.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never heard of a "dummy" bytecode but there is a NOP - which does nothing but take up space.

NOPs can be used to reserve space for a real op which the compiler plugs in later.

Bill
 
J. Insi
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
are you mentioning about bytecode?

Hmmm perhaps this might help you out.

Here Here Take A Read
 
david colais
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What i got from my sources is that a dummy bytecode is a portion of the atual bytecode to be run which is reserved so that while the jvm is using the bytecode, this reserved region serves the purpose of telling the compiler of how to run the code depending on the machine on which the original code was written..

And someone told me that its like patch where the jvm picks up speed while gathering info about the code.

i have no idea to what extent is this info accurate....please clarify if it's not
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
heekphovam heek wrote:. . . telling the compiler of how to run the code depending on the machine on which the original code was written..
That sounds unlikely; there shoul dbe no difference in bytecode written on different machines, and the compiler doesn't run the code.
And someone told me that its like patch where the jvm picks up speed while gathering info about the code. . . .
Don't understand that. Has that anything to do with just-in-time compilation?

By the way, that article is 14 years old. you should compare it with the Java™ Virtual Machine Specification to see whether there have been any changes.
 
D. Ogranos
Ranch Hand
Posts: 214
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, I've got a rather old book about JVM implementations, it mentions that some opcodes can have "quick" variants. Those opcodes have to check class-data, but after doing so once they can be (reasonably) sure that the data is available/valid, so the JVM can replace the normal opcode with a "quick" variant which doesn't perform the data check anymore.

Maybe this is what the OP meant with "dummy" bytecodes?
 
david colais
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@D. Ogranos : This is the exact info i was searching for thanks a lot ........
Can you please elaborate or provide any links which may help?
 
D. Ogranos
Ranch Hand
Posts: 214
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sure. I looked at the book again, the opcodes I mentioned are mostly those that access the constant pool: when the JVM first finds such an opcode, it checks if the referenced object exists, and if so it replaces the opcode with a "quick" variant. Other opcodes where this can be done are most of the invokexxx opcodes, putfield, getfield, putstatic, getstatic, new, instanceof, checkcast and some more.

Note that these "quick" variant opcodes are not part of the JVM specification, they only exists for an implementation of the JVM.

The book is "Java Virtual Machine" by Matthias Kalle Dalheimer, 1997 O'Reilly. Not sure how accurate the info is for todays JVMs...its been a long time since that book was written
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The JVM has definitely changed since 1997. It might be helpful to look at the JVM specification link I posted earlier.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!