now has correct one from kilim/master
The MethodWeaver is not following protocol; it needs to call mv.visitEnd() even for abstract methods.
The code was a bit messy, sometimes passing "Lfoo/Bar;" and sometimes "foo/Bar". This cleans up matters to always use the latter.
The codegen calls Fiber.wrongPC using INVOKESTATIC but the implementation is non-static. To make matters simple we just declare the wrongPC function static.
These are some special methods (mostly on Mailbox) to provide the look-ahead semantics needed for Erlang's selective receive.
In Erjang, we need to run multiple Kilim "instances" concurrently, so we need this static state to be thread-local.
modified: ../../README.txt modified: ../../docs/IFAQ.txt
add classloader support to classweaver
ClassInfo did not have an equals method and List contains checks would a...
basic unobtrusive maven support - just wraps the ant build and deploys t...
…d always return false resulting in duplicate kilim state classes being generated
…s the jar file with a new maven target
…o 1.0, because Kilim has been stable for a while. Future versions of the JVM will make stackmaps mandatory if the classfile major version is >= 50. To enable stackmap support, we upgrade to version 4.x of ASM, which forces upon us a few changes: 1. ASM Visitors are now abstract classes, not interfaces 2. Use LabelNodes instead of Labels everywhere. The second one deserves some explanation. ASM's MethodNode.InsnList uses the 'AbstractInsnNode.next' to thread together instructions. This means that an instruction cannot belong to two different lists, and instructions cannot be squirreled away and added later on (as used to be the case when MethodNode.instructions was an array). Second, Labels contain flags such as Debug (corresponding to line numbers) that cannot be reset. This means that such labels cannot be made targets at a later stage. To accomodate this behavior of ASM, we stop dealing with Labels completely, and only deal with LabelNodes. When generating woven code, we strip the Labels off of LabelNodes to ensure that the labels from the original class file are not reused. The LabelNodes will generate new labels automatically. modified: .classpath modified: .gitignore modified: .settings/org.eclipse.jdt.core.prefs modified: build.sh modified: build.xml modified: docs/manual.html deleted: libs/asm-all-2.2.3.jar new file: libs/asm-all-4.1.jar modified: src/kilim/Constants.java modified: src/kilim/analysis/AsmDetector.java modified: src/kilim/analysis/BasicBlock.java modified: src/kilim/analysis/CallWeaver.java modified: src/kilim/analysis/ClassFlow.java modified: src/kilim/analysis/ClassWeaver.java modified: src/kilim/analysis/MethodFlow.java modified: src/kilim/analysis/MethodWeaver.java modified: src/kilim/analysis/NopInsn.java modified: src/kilim/mirrors/CachedClassMirrors.java modified: src/kilim/mirrors/ClassMirror.java modified: src/kilim/mirrors/Mirrors.java modified: src/kilim/mirrors/RuntimeClassMirrors.java modified: src/kilim/tools/Asm.java modified: src/kilim/tools/DumpClass.java modified: src/kilim/tools/FlowAnalyzer.java modified: test.sh modified: test/kilim/test/ex/ExJSR.j
…ny pausable calls, then the prelude was being generated incorrectly: the fiber argument was loaed onto the stack, but not popped on return. modified: src/kilim/analysis/MethodWeaver.java modified: test/kilim/test/ex/ExBasicBlock.java
From the issue page: "The kilim.analysis.ClassWeaver class maintains a static list of state classes that have been generated. Therefore, when used in Eclipse, if kilim.S_L is generated once when one eclipse project is built, then it will not be generated again in a second eclipse project that requires it. " modified: src/kilim/analysis/ClassWeaver.java
modified: src/kilim/mirrors/CachedClassMirrors.java modified: src/kilim/mirrors/Detector.java
…ction. modified: .classpath modified: examples/kilim/examples/Reflect.java modified: src/kilim/Task.java modified: src/kilim/mirrors/CachedClassMirrors.java
"Local vars not restored properly after exception is thrown" Thanks to ntherning (https://github.com/ntherning) for both the test case and the fix. modified: src/kilim/analysis/MethodWeaver.java modified: test/kilim/test/TestYieldExceptions.java modified: test/kilim/test/ex/ExCatch.java
Problem: In Frame.merge the operand stacks were being examined pointwise for differences, but due to an incorrect comparison, the analysis assumed that the stack had not changed. TestYield/ExLoop are the relevant unit test and example code to exercise this functionality. modified: .classpath modified: src/kilim/analysis/Frame.java modified: src/kilim/analysis/Usage.java modified: src/kilim/tools/Asm.java modified: src/kilim/tools/P.java modified: test/kilim/test/TestYield.java new file: test/kilim/test/ex/ExLoop.java modified: test/kilim/test/ex/ExYieldStack.java
… now to avoid holding on to an open jar file under memory pressure modified: src/kilim/analysis/FileLister.java
modified: src/kilim/WeavingClassLoader.java modified: src/kilim/analysis/FileLister.java