http://permalink.gmane.org/gmane.comp.java.objectweb.asm hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4094 <pre>Can we see the proposed interfaces, if you already have them? And maybe an example showing how they would be used for a backward analysis? EricEliot Moss &lt;moss&lt; at &gt;cs.umass.edu&gt; a écrit :You mention backward flow analysis.  We are indeed working on it and I hope to have something within the next month or so. Here are some things to pass on about the design: - Even back analyses require first a forward analysis to discover    the flow graph.  We have found it useful to build a backward    graph from the forward one; this allows the most space efficient    backward graph.  We found it sensible to separate graph building    from the actual analysis -- however, we intend to test the cost    of this and can forward the mixed forward graph building + analysis    that the current Analyzer class does if that seems advised. - Most backward analyses need some kind of forward analysis first,    in addition to flow graph construction -- if only the type information. - This led to the notion of a *chain</pre> Eric Bruneton 2012-05-16T16:37:43 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4093 <pre> do you use SCC for "strongly connected components" here? Then what do you do if the whole method is a single SCC (ie. only one node in the SCC dag)? is it possible that you have an exception handler that only partially covers the component (and its transitive closure) you want to split? Ie. that this handler also covers some other code? Then the handler code could be duplicated? what do you call a subcomponent here? a strongly connected "sub component"? Because if you run an algorithm to find the maximal strongly connected components, and use it on a strongly connected component C, you will not get any "sub component" of C, but only C itself. Eric </pre> ebruneton< at >free.fr 2012-05-17T06:47:29 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4092 <pre>Rémi, In asm.Attribute, the method closer to what I need appears to be read() actually, because it populates Attribute.value . I'm instead writing directly to that field: // Scala code def createJAttribute(name: String, b: Array[Byte], offset: Int, len: Int): asm.Attribute = { val dest = new Array[Byte](len); System.arraycopy(b, offset, dest, 0, len); new asm.CustomAttr(name, dest) } For clarity, the subclass I'm using looks like: // Java code public class CustomAttr extends Attribute { public CustomAttr(final String type, final byte[] value) { super(type); super.value = value; } } For the use case above a subclass does a fine job, but anyway I wanted to ask whether Attribute.value could be made public. best regards, Miguel http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded </pre> Garcia Gutierrez Miguel Alfredo 2012-05-16T18:45:17 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4091 <pre>Eugene, I'm using those methods as-is (calling them from a subclass). If they were public I could use them instead as follows (from an unrelated class): // Scala code import scala.tools.asm.util.CheckMethodAdapter if (sym.isMethod) { CheckMethodAdapter checkMethodSignature sig } // requires asm-util.jar else if (sym.isTerm) { CheckMethodAdapter checkFieldSignature sig } else { CheckMethodAdapter checkClassSignature sig } best regards, Miguel http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/ </pre> Garcia Gutierrez Miguel Alfredo 2012-05-16T18:50:53 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4090 <pre> value is only used for unknown attribute, otherwise it's better to implements read and write. For unknown attribute, write(null, null, 0, 0, 0).toByteArray() should give you what you want. I see no problem with that. Rémi </pre> Rémi Forax 2012-05-16T14:31:08 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4089 <pre> This is pretty much by design. The Attribute class is only used directly for unknown attributes. For your own attributes you should use your own subclasses. See section A3 in ASM User's Guide at http://download.forge.objectweb.org/asm/asm4-guide.pdf Though most of the stuff can be now stored using regular annotations, instead of attributes... Could you elaborate why you need something else in these methods which are supposedly checking that signatures are valid for the JVM... regards, Eugene </pre> Eugene Kuleshov 2012-05-16T14:24:32 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4088 <pre> Hi, In the Scala compiler backend we're subclassing asm.Attribtue and asm.util.CheckMethodAdapter to access functionality which is not public, respectively: - Attribute's value field - CheckMethodAdapter's checkClassSignature(), checkMethodSignature(), and checkFieldSignature() methods If those members were public to start with, my team could automate our build some more (by checking out ASM from ObjectWeb's SVN). Is it ok with you making the above members public? Miguel http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/ </pre> miguelalfredo.garcia< at >epfl.ch 2012-05-16T14:04:43 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4087 <pre> ebruneton&lt; at &gt;free.fr writes: My approach is somewhat different, but it's extremely helpful to get another perspective. Thanks for the analysis and very elaborate and helpful description! Right. I actually do handle exceptions, currently - see below. Yes, and I haven't done that yet. What I am trying to do is not as general as what you're suggesting: It's still possible to write large methods that my approach won't split successfully. On the other hand, the splitting strategy I use is much simpler. My intention is to first fully implement this and then see how well it works with actual compilers. Your strategy looks like the appropriate next step if that doesn't work as well as I'm hoping. (I'm betting on the fact that the simple strategy will either work, or a compiler's code generator can easily be adjusted to make it work well.) That is only necessary if the split-out method is not a tail method, i.e. the call to it in the end product is not a tail call. I only split at appropriate points in </pre> Michael Sperber 2012-05-16T07:47:17 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4086 <pre>You mention backward flow analysis. We are indeed working on it and I hope to have something within the next month or so. Here are some things to pass on about the design: - Even back analyses require first a forward analysis to discover the flow graph. We have found it useful to build a backward graph from the forward one; this allows the most space efficient backward graph. We found it sensible to separate graph building from the actual analysis -- however, we intend to test the cost of this and can forward the mixed forward graph building + analysis that the current Analyzer class does if that seems advised. - Most backward analyses need some kind of forward analysis first, in addition to flow graph construction -- if only the type information. - This led to the notion of a *chained* analysis, where one has an array of Frame&lt;V&gt; computed from some previous analysis and desires to compute an array of Frame&lt;W&gt; using the V values (and the flowing W values). This leads to e</pre> Eliot Moss 2012-05-15T21:44:01 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4085 <pre>I've been thinking about the problem you try to address, here are my thoughts. I don't know the algorithm you are using, maybe I just described what you are already doing. First of all, I suppose there is no JSR/RET instruction, and no dead code (they can be easily removed with a JSRInlinerAdapter and DeadCodeRemovalAdapter - see ASM Guide). I also suppose there is no exception handler (to be done). Then, note that it is possible to have a method made of a single very large basic block. Thus, working at the basic block level (i.e. treating them as indivisible atoms) is not general enough. You could do a first pass where you split the basic blocks that are too large, but for full generality, in the following I will work at the instruction level. Now suppose you have identified some code you want to extract into a separate method. This code needs some stack and local variables as inputs and outputs. A simple but not optimal strategy is to pass it all the stack values and all the local variables, even the on</pre> ebruneton< at >free.fr 2012-05-15T17:16:15 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4084 <pre> Eric Bruneton &lt;ebruneton&lt; at &gt;gmail.com&gt; writes: Could you elaborate? All the offsets I see in Label are ints, and Label.resolve calculates them correctly, I read the code right. If Label.resolve sees an offset &gt; Short.MAX_VALUE, it sets the needUpdate flag, so I'll know later there's a potential problem. Sure, the offset it writes into the code is invalid, but can't I look at the Label again later, retrieving the correct offset? </pre> Michael Sperber 2012-05-15T11:30:03 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4083 <pre> Rémi Forax &lt;forax&lt; at &gt;univ-mlv.fr&gt; writes: No, it's too late, because the visitor has already run. There's no way from inside ClassWriter or MethodWriter to reach back up and re-run it. </pre> Michael Sperber 2012-05-15T06:28:44 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4082 <pre> For a generator, you can do the code size evaluation on the visitor, and revert to use the tree API if the size is too big and you want to split it. Rémi </pre> Rémi Forax 2012-05-14T09:55:21 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4081 <pre> Eric Bruneton &lt;ebruneton&lt; at &gt;free.fr&gt; writes: I very much appreciate the feedback! I know there's a lot of interaction with the core package right now, which I hope to reduce once I really know what I'm doing. The current set of changes still carries the traces from some abandoned attempts. Going to the tree API would have a couple of unpleasant side effects, though: It would only work for code generators using the tree API, and incur its performance disadvantages. Also, I'd have to *always* estimate code size in the tree API, which would slow things down even further. On the other hand, the check in the core API for the size limit is trivial, and you'd only pay for the splitting work when it's necessary. I saw the code in Label.java, but no other code that knows about the 64k limit: If I understand it correctly, the only affected code is for backpatching forward branches. (While it's closely related to the method-size limit, this is mostly about the limit in branch-offset size, right?) But isn't all</pre> Michael Sperber 2012-05-14T09:48:23 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4080 <pre> I downloaded the sources to do a svn diff with my local ASM repository. I think the approach you are using is ok to design and test your algorithm, but in order for this to be integrated in ASM, you will need to avoid any change in the core package. For this you will need to move from the byte array level to the tree API, which will be less error prone. This would complicate bytecode size computations if you would keep exact sizes, but I think you can work instead with conservative estimates of these sizes, as in CodeSizeEvaluator. I see two reasons to move from the byte array level to the tree API. The first is to avoid exposing private implementation details in the core package, as in your current design. The second is that this approach is probably fundamentally flawed: it seems that your code is parsing the instructions at the byte array level to rebuild some high level data structures, and in particular it seems to parse bytecode offsets from jump instructions. But ASM is using the assumption that </pre> Eric Bruneton 2012-05-13T14:04:25 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4079 <pre> a diff with 4.0 is ok. I was looking for something like this: http://websvn.ow2.org/comp.php?repname=asm Eric </pre> Eric Bruneton 2012-05-13T12:33:16 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4078 <pre> Eric Bruneton &lt;ebruneton&lt; at &gt;free.fr&gt; writes: Just to be sure I understand you correctly: I based my stuff on ASM 4.0, which is what the project I'm involved in is using, but you'd rather have a version on the current ASM head from Subversion, right? Or would a diff between 4.0 and my stuff also work for you? </pre> Michael Sperber 2012-05-13T08:45:34 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4077 <pre> is it possible to view a diff with ASM HEAD, to better see the proposed changes? Eric </pre> Eric Bruneton 2012-05-12T12:43:40 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4076 <pre> I've made some progress on hacking ASM such that it automatically splits methods larger than 64k into several sub-methods. This is very rough work at the moment, and a lot of stuff doesn't work yet, but it shows where it's all going, and the first couple of examples do work. If someone is interested, have a look at: https://bitbucket.org/sperber/asm-method-size Of course, help would be much welcome. </pre> Michael Sperber 2012-05-11T12:02:57 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4075 <pre> Yesterday [1] a new backend based on ASM was merged into the Scala compiler, hopefully to become the default backend in the near future. The motivation to use ASM was speed and emitting class file in format version 50 and up. In both areas ASM performs great. Looking into the future, there's early brainstorming on invokedynamic [2], so stay tuned (better yet, join the discussion!) regards, Miguel http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/ [1] https://github.com/scala/scala/commit/454c2a0c775c92be7f2a741bb6ab17b55f1eddb1 [2] http://mail.openjdk.java.net/pipermail/graal-dev/2012-May/000038.html http://mail.openjdk.java.net/pipermail/graal-dev/2012-May/000040.html https://groups.google.com/d/topic/jvm-languages/eEp3Z8tS8wo/discussion </pre> miguelalfredo.garcia< at >epfl.ch 2012-05-09T10:02:31 http://permalink.gmane.org/gmane.comp.java.objectweb.asm/4074 <pre> :) Rémi </pre> Rémi Forax 2012-05-03T18:37:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.objectweb.asm