headers
Nicholson, Jonathan O H | 7 Mar 2007 15:33
Picon
Favicon

Invokation and return statement analysis with BCEL

Heya guys,

I'm doing a research project in formal methods, and I'm looking into
BCEl to be able to provide me with certain information about a given
class (there are benefits, from our point of view, to class inspection
over source code inspection that I need not go into).

I have managed to program a vast majority of the features we require
pretty quickly, and I am more than glad to see the programs dependency
on CFParse disappear. The method that does the analysis is in this
format:

foreach(JavaClass c : somearray)
{
  // Inspect the class
  InstructionList list = c.getInstructionList();
  foreach(Instruction i : list.getInstructions())
  {
    switch(i.getOpcode())
    {
      // do something when certain instructions are found
    }
  }
}

There is no modification of the classes as they are processed, and
information is basically dumped into a database (currently to the screen
while debugging) as its found

Problems:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Arrin Daley | 8 Mar 2007 00:08
Picon
Picon

Re: Invokation and return statement analysis with BCEL

Hi Mac

1.
What type are you trying to find out from ARETURN? All the type(s) that 
could be returned? or a superclass of all the types that could be returned?

If you are trying to track down all of the types that might be returned 
(the subclasses) then I'm guessing you will need to do stack simulation

There are some classes in BCEL's verifer project that will help you out 
by doing stack simulation this will let you access the types on the 
stack. Have a look at the org.apache.bcel.verifier.structurals

<http://djvm/internal/bcel-5.2/apidocs/org/apache/bcel/verifier/structurals/package-frame.html> 
package in BCEL. It's real purpose is verification but we have used it 
to find the types returned from AALOAD operations so finding the types 
returned from ARETURN should be no harder.

Your problem if your goal is to capture all types that could be returned 
the current stack simulation does a merge where it finds the superclass 
of the two or more subclasses found. If you extend the current 
ExecutionVisitor you could modify this behaviour and record all types.
The other thing that is a little annoying is that the ExecutionVisitor 
uses a InstConstraintVisitor, it seems that the JustIICE verifier has a 
more strict notion of what is valid code than the original java virtual 
machine so when you modify ExecutionVisitor make it so that it doesn't 
use a InstConstraint visitor, otherwise you will get JustICE telling you 
about errors in code the JVM passes.

2.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Nicholson, Jonathan O H | 8 Mar 2007 03:37
Picon
Favicon

RE: Invokation and return statement analysis with BCEL

Thanks Arrin,

I'll have a look at the classes you suggested, I wasn't sure if a visitor
was the way to go, so far I've been mimicing the structure of the program we
had based on CFParse... And as you can imagine nested loops for my purposes
are very large and difficult to understand/maintain. Although logically
using a good design pattern such as Visitor is better than using an
anti-pattern such as what I have. [Before finishing this email I've been
playing with making a visitor and itsmuch simpler than I had originally
thought, same problems when inside methods but a lot neater code generally
and easier to see where things go, thanks for the suggestion!!!]

To answer your questions I think its probably best to give some examples.
Therefore with return statements:

public class c
{
	Object o = new Object();

	public Object someMethod(int i)
	{
		Integer myInt = new Integer(i);
		if(i < 5)
			return o;
		if(i < 10)
			return new Integer();
		if(i < 15)
			return myInt;
		if(i < 20)
			return null;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Schoeberl | 8 Mar 2007 12:55

Re: Invokation and return statement analysis with BCEL

> There are some classes in BCEL's verifer project that will help you out 
> by doing stack simulation this will let you access the types on the 
> stack. Have a look at the org.apache.bcel.verifier.structurals 
>
<http://djvm/internal/bcel-5.2/apidocs/org/apache/bcel/verifier/structurals/package-frame.html> 

interesting, but the link is broken.

Martin
Permalink | Reply | 1 comment |
headers
Nicholson, Jonathan O H | 8 Mar 2007 23:10
Picon
Favicon

RE: Invokation and return statement analysis with BCEL

Martin

Try this one instead:
http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/verifier/structurals/
package-summary.html 

Direct off the main BCEL webpage.

Jon

-----Original Message-----
From: Martin Schoeberl [mailto:martin <at> jopdesign.com] 
Sent: 08 March 2007 11:56
To: BCEL Users List; arrin.daley <at> anu.edu.au
Subject: Re: Invokation and return statement analysis with BCEL

> There are some classes in BCEL's verifer project that will help you 
> out by doing stack simulation this will let you access the types on 
> the stack. Have a look at the org.apache.bcel.verifier.structurals
> <http://djvm/internal/bcel-5.2/apidocs/org/apache/bcel/verifier/struct
> urals/package-frame.html>

interesting, but the link is broken.

Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-user-unsubscribe <at> jakarta.apache.org
For additional commands, e-mail: bcel-user-help <at> jakarta.apache.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eugene Kuleshov | 23 Mar 2007 02:15
Picon
Gravatar

JavaOne session Bytecode Manipulation Techniques for Dynamic Applications for the JVM


  Sorry for slight offtopic, but I'd like to announce JavaOne session 
TS-1326 - "Bytecode Manipulation Techniques for Dynamic Applications for 
the Java Virtual Machine" [1].

  The talk is presented by Tom Ware from Oracle, Tim Eck and yours truly 
(Eugene Kuleshov) from Terracotta and Charles Nutter from JRuby/Sun. We 
are planning to show examples of the bytecode transformations from the 
Oracle TopLink, Terracotta DSO and JRuby Compiler from the product 
developers. All those products choose ASM bytecode framework for its 
performance, simplicity and size.

  If you have any ideas or suggestions on what you would like to see in 
this talk please let me know.

  Here is the session abstract:/
/

    /The Java virtual machine (JVM) provides a proven platform for
    running reliable and high-performance applications. Its
    class-loading architecture enables dynamic applications, frameworks,
    and even languages other than the Java programming language to run
    and coexist in the same JVM.

    To make things even more dynamic while keeping an acceptable
    performance mark, many of those frameworks are generating Java
    bytecode, skipping compilation from Java technology sources or even
    instrumenting existing Java platform classes to introduce additional
    logic. This approach is used by several Java Persistence API (JPA)
    engines and Enterprise JavaBeans (EJB) 3 (JSR 220) containers to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Bengtson | 28 Mar 2007 20:57
Favicon

Bug 41974 and 39695


Hi,

Is it possible someone to look at the patches attached to these use cases and
commit, if you like.

Thanks,

Erik Bengtson
Permalink | Reply | 2 comments |
headers
Torsten Curdt | 28 Mar 2007 21:12
Picon
Favicon
Gravatar

Re: Bug 41974 and 39695

> Is it possible someone to look at the patches attached to these use  
> cases and
> commit, if you like.

Hey!

Somehow I missed those in my last batch.

Will try to look into this tomorrow!

cheers
--
Torsten
Permalink | Reply | 1 comment |

Gmane