> On Feb 17, 2018, at 4:01 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > >> Most classes should naturally use backward references exclusively, since >> entries tend to be generated bottom-up. >> (In theory. If there are counter examples produced by any mainstream >> bytecode generators, that would be good to know.) > > Currently, javac and ecj tends to generate their constants in the "wrong > order". > ecj: > #15 = Methodref #16.#18 // > java/lang/Class.desiredAssertionStatus:()Z > #16 = Class #17 // java/lang/Class > #17 = Utf8 java/lang/Class > #18 = NameAndType #19:#20 // desiredAssertionStatus:()Z > #19 = Utf8 desiredAssertionStatus > #20 = Utf8 ()Z > > javac: > ... > #20 = Methodref #65.#66 // > java/lang/Class.desiredAssertionStatus:()Z > ... > #65 = Class #75 // java/lang/Class > #66 = NameAndType #76:#77 // desiredAssertionStatus:()Z > ... > #75 = Utf8 java/lang/Class > #76 = Utf8 desiredAssertionStatus > #77 = Utf8 ()Z > > It means nothing now because we only cares about constants that can introduce > cycles so CONSTANT_Dynamic, it may be an issue in the future if by example a > NameAndType can reference a constant with cycle, the code of javac and ecj > will have to be changed.
Yep, looks like my depth-first assumption is wrong. Here's a javac constant pool for an empty class: #1 = Methodref #3.#10 // java/lang/Object."<init>":()V #2 = Class #11 // ConstantPool #3 = Class #12 // java/lang/Object #4 = Utf8 <init> #5 = Utf8 ()V #6 = Utf8 Code #7 = Utf8 LineNumberTable #8 = Utf8 SourceFile #9 = Utf8 ConstantPool.java #10 = NameAndType #4:#5 // "<init>":()V #11 = Utf8 ConstantPool #12 = Utf8 java/lang/Object I can kind of squint and see the logic, but there's no simple pattern here. Forward and backward references both occur. I'll ask our code gen experts about what they'd expect from Dynamic, and whether it's easy to assume they always point in one direction or the other. —Dan
