From john.r.rose at oracle.com Wed Nov 2 22:51:32 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 03 Nov 2011 05:51:32 +0000 Subject: hg: mlvm/mlvm/jdk: add experimental macosx-port patch, FTR Message-ID: <20111103055134.15E3C47213@hg.openjdk.java.net> Changeset: 77386404343c Author: jrose Date: 2011-11-02 22:50 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/77386404343c add experimental macosx-port patch, FTR + bsd-port-to-macosx-port.patch ! series From john.r.rose at oracle.com Wed Nov 2 22:52:52 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 03 Nov 2011 05:52:52 +0000 Subject: hg: mlvm/mlvm/jdk: math-lazy: checkpoint Message-ID: <20111103055252.F364147214@hg.openjdk.java.net> Changeset: e8bd23b1ede1 Author: jrose Date: 2011-11-02 22:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e8bd23b1ede1 math-lazy: checkpoint + meth-lazy.patch ! series From john.r.rose at oracle.com Wed Nov 2 22:54:40 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 03 Nov 2011 05:54:40 +0000 Subject: hg: mlvm/mlvm/hotspot: work around problem with macosx-port Message-ID: <20111103055441.6DFDC47215@hg.openjdk.java.net> Changeset: c9160995189a Author: jrose Date: 2011-11-02 22:54 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c9160995189a work around problem with macosx-port ! mac-tweaks.patch ! series From john.r.rose at oracle.com Wed Nov 2 22:54:49 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 03 Nov 2011 05:54:49 +0000 Subject: hg: mlvm/mlvm/hotspot: math-lazy: checkpoint Message-ID: <20111103055449.8ACDE47216@hg.openjdk.java.net> Changeset: 29fccd72eabb Author: jrose Date: 2011-11-02 22:54 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/29fccd72eabb math-lazy: checkpoint + meth-lazy.patch + meth-lazy.txt ! series From henri.gomez at gmail.com Thu Nov 3 00:53:10 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 3 Nov 2011 08:53:10 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. Message-ID: Hi to all, I'd like to provide OpenJDK 8 with MLVM to OS/X users as I'm doing for month with OpenJDK 7 on http://code.google.com/p/openjdk-osx-build/. I'm trying to build it using Stephen scripts (https://gist.github.com/243072) for now but I still can't get it built : /Users/henri/Downloads/openjdk8/mlvm/sources/ALT_COMPILER_PATH/g++ -m64 -Wl,-install_name, at rpath/libjvm.dylib -dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 -fPIC \ -Xlinker -rpath -Xlinker @loader_path/. -Xlinker -rpath -Xlinker @loader_path/.. -Xlinker -install_name -Xlinker @rpath/libjvm.dylib -o libjvm.dylib abstractCompiler.o accessFlags.o ad_x86_64.o ad_x86_64_clone.o ad_x86_64_expand.o ad_x86_64_format.o ad_x86_64_gen.o ad_x86_64_misc.o ad_x86_64_peephole.o ad_x86_64_pipeline.o adaptiveSizePolicy.o addnode.o adjoiningGenerations.o adjoiningVirtualSpaces.o advancedThresholdPolicy.o ageTable.o allocation.o allocationStats.o aprofiler.o arguments.o array.o arrayKlass.o arrayKlassKlass.o arrayOop.o asPSOldGen.o asPSYoungGen.o asParNewGeneration.o assembler.o assembler_bsd_x86.o assembler_x86.o atomic.o attachListener.o attachListener_bsd.o barrierSet.o basicLock.o bcEscapeAnalyzer.o biasedLocking.o binaryTreeDictionary.o bitMap.o block.o blockOffsetTable.o bsd_x86_64.o buildOopMap.o bytecode.o bytecodeHistogram.o bytecodeInfo.o bytecodeInterpreter.o bytecodeInterpreterWithChecks.o bytecodeInterpreter_x86.o bytecodeStream.o bytecodeTracer.o bytecodes.o bytecodes_x86.o c1_CFGPrinter.o c1_Canonicalizer.o c1_CodeStubs_x86.o c1_Compilation.o c1_Compiler.o c1_Defs.o c1_FpuStackSim_x86.o c1_FrameMap.o c1_FrameMap_x86.o c1_GraphBuilder.o c1_IR.o c1_Instruction.o c1_InstructionPrinter.o c1_LIR.o c1_LIRAssembler.o c1_LIRAssembler_x86.o c1_LIRGenerator.o c1_LIRGenerator_x86.o c1_LinearScan.o c1_LinearScan_x86.o c1_MacroAssembler_x86.o c1_Optimizer.o c1_Runtime1.o c1_Runtime1_x86.o c1_ValueMap.o c1_ValueSet.o c1_ValueStack.o c1_ValueType.o c1_globals.o c2_globals.o c2_init_x86.o c2compiler.o cSpaceCounters.o callGenerator.o callnode.o cardTableExtension.o cardTableModRefBS.o cardTableRS.o cfgnode.o chaitin.o chaitin_bsd.o ciArray.o ciArrayKlass.o ciCPCache.o ciCallSite.o ciConstant.o ciConstantPoolCache.o ciEnv.o ciExceptionHandler.o ciField.o ciFlags.o ciInstance.o ciInstanceKlass.o ciInstanceKlassKlass.o ciKlass.o ciKlassKlass.o ciMethod.o ciMethodBlocks.o ciMethodData.o ciMethodHandle.o ciMethodKlass.o ciNullObject.o ciObjArray.o ciObjArrayKlass.o ciObjArrayKlassKlass.o ciObject.o ciObjectFactory.o ciSignature.o ciStreams.o ciSymbol.o ciType.o ciTypeArray.o ciTypeArrayKlass.o ciTypeArrayKlassKlass.o ciTypeFlow.o ciUtilities.o classFileError.o classFileParser.o classFileStream.o classLoader.o classLoadingService.o classes.o classify.o cmsAdaptiveSizePolicy.o cmsCollectorPolicy.o cmsGCAdaptivePolicyCounters.o cmsLockVerifier.o cmsPermGen.o coalesce.o codeBlob.o codeBuffer.o codeCache.o collectedHeap.o collectionSetChooser.o collectorCounters.o collectorPolicy.o compactibleFreeListSpace.o compactingPermGenGen.o compilationPolicy.o compile.o compileBroker.o compileLog.o compiledIC.o compiledICHolderKlass.o compiledICHolderOop.o compilerOracle.o compressedStream.o concurrentG1Refine.o concurrentG1RefineThread.o concurrentGCThread.o concurrentMark.o concurrentMarkSweepGeneration.o concurrentMarkSweepThread.o concurrentMarkThread.o connode.o constMethodKlass.o constMethodOop.o constantPoolKlass.o constantPoolOop.o constantTag.o copy.o coroutine.o cpCacheKlass.o cpCacheOop.o cppInterpreter.o cppInterpreter_x86.o debug.o debugInfo.o debugInfoRec.o debug_x86.o decoder.o decoder_bsd.o defNewGeneration.o deoptimization.o depChecker_x86.o dependencies.o dfa_x86_64.o dict.o dictionary.o dirtyCardQueue.o disassembler.o divnode.o doCall.o domgraph.o dtraceAttacher.o dtraceJSDT.o dtraceJSDT_bsd.o dump.o dump_x86_64.o elfFile.o elfStringTable.o elfSymbolTable.o errorReporter.o escape.o events.o evmCompat.o exceptionHandlerTable.o exceptions.o fieldDescriptor.o fieldType.o filemap.o forte.o fprofiler.o frame.o frame_x86.o freeBlockDictionary.o freeChunk.o freeList.o g1AllocRegion.o g1BlockOffsetTable.o g1CollectedHeap.o g1CollectorPolicy.o g1ErgoVerbose.o g1HRPrinter.o g1MMUTracker.o g1MarkSweep.o g1MemoryPool.o g1MonitoringSupport.o g1RemSet.o g1SATBCardTableModRefBS.o g1_globals.o gSpaceCounters.o gcAdaptivePolicyCounters.o gcCause.o gcLocker.o gcNotifier.o gcPolicyCounters.o gcStats.o gcTaskManager.o gcTaskThread.o gcUtil.o gcm.o genCollectedHeap.o genMarkSweep.o genRemSet.o generateOopMap.o generateOptoStub.o generation.o generationCounters.o generationSpec.o globalDefinitions.o globals.o graphKit.o growableArray.o hSpaceCounters.o handles.o hashtable.o heap.o heapDumper.o heapInspection.o heapRegion.o heapRegionRemSet.o heapRegionSeq.o heapRegionSet.o heapRegionSets.o histogram.o icBuffer.o icBuffer_x86.o icache.o icache_x86.o idealGraphPrinter.o idealKit.o ifg.o ifnode.o immutableSpace.o indexSet.o init.o instanceKlass.o instanceKlassKlass.o instanceMirrorKlass.o instanceOop.o instanceRefKlass.o intHisto.o interfaceSupport.o interp_masm_x86_64.o interpreter.o interpreterRT_x86_64.o interpreterRuntime.o interpreter_x86_64.o invocationCounter.o iterator.o java.o javaAssertions.o javaCalls.o javaClasses.o jni.o jniCheck.o jniFastGetField.o jniFastGetField_x86_64.o jniHandles.o jniPeriodicChecker.o jvm.o jvm_bsd.o jvmtiClassFileReconstituter.o jvmtiCodeBlobEvents.o jvmtiEnter.o jvmtiEnterTrace.o jvmtiEnv.o jvmtiEnvBase.o jvmtiEnvThreadState.o jvmtiEventController.o jvmtiExport.o jvmtiExtensions.o jvmtiGetLoadedClasses.o jvmtiImpl.o jvmtiManageCapabilities.o jvmtiRawMonitor.o jvmtiRedefineClasses.o jvmtiTagMap.o jvmtiThreadState.o jvmtiTrace.o jvmtiUtil.o klass.o klassKlass.o klassOop.o klassVtable.o lcm.o library_call.o linkResolver.o live.o loaderConstraints.o location.o locknode.o loopPredicate.o loopTransform.o loopUnswitch.o loopnode.o loopopts.o lowMemoryDetector.o machnode.o macro.o management.o markOop.o markSweep.o matcher.o memRegion.o memnode.o memoryManager.o memoryPool.o memoryService.o memprofiler.o methodComparator.o methodDataKlass.o methodDataOop.o methodHandleWalk.o methodHandles.o methodHandles_x86.o methodKlass.o methodLiveness.o methodOop.o monitorChunk.o mulnode.o multnode.o mutableNUMASpace.o mutableSpace.o mutex.o mutexLocker.o mutex_bsd.o nativeInst_x86.o nativeLookup.o nmethod.o node.o numberSeq.o objArrayKlass.o objArrayKlassKlass.o objArrayOop.o objectMonitor.o objectStartArray.o oop.o oopFactory.o oopMap.o oopMapCache.o oopRecorder.o oopsHierarchy.o opcodes.o orderAccess.o os.o osThread.o osThread_bsd.o os_bsd.o os_bsd_x86.o os_posix.o ostream.o output.o parCardTableModRefBS.o parGCAllocBuffer.o parMarkBitMap.o parNewGeneration.o parallelScavengeHeap.o park.o parse1.o parse2.o parse3.o parseHelper.o pcDesc.o pcTasks.o perf.o perfData.o perfMemory.o perfMemory_bsd.o permGen.o phase.o phaseX.o placeholders.o port.o postaloc.o preserveException.o privilegedStack.o promotionInfo.o psAdaptiveSizePolicy.o psCompactionManager.o psGCAdaptivePolicyCounters.o psGenerationCounters.o psMarkSweep.o psMarkSweepDecorator.o psMemoryPool.o psOldGen.o psParallelCompact.o psPermGen.o psPromotionLAB.o psPromotionManager.o psScavenge.o psTasks.o psVirtualspace.o psYoungGen.o ptrQueue.o quickSort.o referencePolicy.o referenceProcessor.o reflection.o reflectionUtils.o reg_split.o regalloc.o register.o register_definitions_x86.o register_x86.o regmask.o relocInfo.o relocInfo_x86.o relocator.o resolutionErrors.o resourceArea.o restore.o rewriter.o rframe.o rootnode.o runtime.o runtimeService.o runtime_x86_64.o safepoint.o satbQueue.o scopeDesc.o serialize.o serviceThread.o set.o sharedHeap.o sharedRuntime.o sharedRuntimeTrans.o sharedRuntimeTrig.o sharedRuntime_x86_64.o signature.o simpleThresholdPolicy.o sizes.o space.o spaceCounters.o spaceDecorator.o sparsePRT.o specialized_oop_closures.o split_if.o stackMapFrame.o stackMapTable.o stackValue.o stackValueCollection.o statSampler.o stringopts.o stubCodeGenerator.o stubGenerator_x86_64.o stubRoutines.o stubRoutines_bsd.o stubRoutines_x86_64.o stubs.o subnode.o superword.o survRateGroup.o sweeper.o symbol.o symbolTable.o synchronizer.o systemDictionary.o task.o taskqueue.o templateInterpreter.o templateInterpreter_x86_64.o templateTable.o templateTable_x86_64.o tenuredGeneration.o thread.o threadCritical_bsd.o threadLS_bsd_x86.o threadLocalAllocBuffer.o threadLocalStorage.o threadService.o thread_bsd_x86.o timer.o type.o typeArrayKlass.o typeArrayKlassKlass.o typeArrayOop.o unhandledOops.o universe.o unsafe.o utf8.o vectornode.o vectset.o verificationType.o verifier.o vframe.o vframeArray.o vframe_hp.o virtualspace.o vmCMSOperations.o vmError.o vmError_bsd.o vmGCOperations.o vmPSOperations.o vmStructs.o vmSymbols.o vmThread.o vm_operations.o vm_operations_g1.o vm_version.o vm_version_bsd_x86.o vm_version_x86.o vmreg.o vmreg_x86.o vtableStubs.o vtableStubs_x86_64.o workgroup.o xmlstream.o yieldingWorkgroup.o -lm -pthread; \ \ rm -f libjvm.dylib.1; ln -s libjvm.dylib libjvm.dylib.1; \ [ -f libjvm_g.dylib ] || { ln -s libjvm.dylib libjvm_g.dylib; ln -s libjvm.dylib.1 libjvm_g.dylib.1; }; \ } Linking vm... [ -f libsaproc_g.dylib ] || { ln -s libsaproc.dylib libsaproc_g.dylib; } dsymutil libjvm.dylib warning: no debug symbols in executable (-arch x86_64) echo "Doing vm.make build:" Doing vm.make build: All done. cd bsd_amd64_compiler2/fastdebug && ./test_gamma openjdk full version "1.7.0-b147-20110923" Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object ./test_gamma: line 13: ./gamma: No such file or directory make[4]: *** [fastdebug] Error 127 make[3]: *** [generic_build2] Error 2 make[2]: *** [fastdebug] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 My build environment is OSX 10.6.8, 64bits, XCode 4.0.1 and OpenJDK 7 from macosx-port. I know some of you here are building it on OS/X and may have success. Are you using XCode 4 or a previous one ? Advices welcomed. From stephen.bannasch at deanbrook.org Thu Nov 3 08:13:48 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Thu, 3 Nov 2011 11:13:48 -0400 Subject: hg: mlvm/mlvm/jdk: add experimental macosx-port patch, FTR In-Reply-To: <20111103055134.15E3C47213@hg.openjdk.java.net> References: <20111103055134.15E3C47213@hg.openjdk.java.net> Message-ID: At 5:51 AM +0000 11/3/11, john.r.rose at oracle.com wrote: >Changeset: 77386404343c >Author: jrose >Date: 2011-11-02 22:50 -0700 >URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/77386404343c > >add experimental macosx-port patch, FTR > >+ bsd-port-to-macosx-port.patch >! series Not certain what this commit was fixing but I am still getting this error: Linking vm... [ -f libsaproc_g.dylib ] || { ln -s libsaproc.dylib libsaproc_g.dylib; } dsymutil libjvm.dylib warning: no debug symbols in executable (-arch x86_64) echo "Doing vm.make build:" Doing vm.make build: All done. cd bsd_amd64_compiler2/fastdebug && ./test_gamma openjdk full version "1.7.0-internal-stephen_2011_10_22_22_58-b00" Error occurred during initialization of VM Unable to load native library: dlopen(/Users/stephen/dev/java/src/mlvm/sources/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/libjava.dylib, 1): image not found ./test_gamma: line 13: ./gamma: No such file or directory From henri.gomez at gmail.com Thu Nov 3 08:21:45 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 3 Nov 2011 16:21:45 +0100 Subject: hg: mlvm/mlvm/jdk: add experimental macosx-port patch, FTR In-Reply-To: References: <20111103055134.15E3C47213@hg.openjdk.java.net> Message-ID: > Not certain what this commit was fixing but I am still getting this error: > > Linking vm... > [ -f libsaproc_g.dylib ] || { ln -s libsaproc.dylib libsaproc_g.dylib; } > dsymutil libjvm.dylib > warning: no debug symbols in executable (-arch x86_64) > echo "Doing vm.make build:" > Doing vm.make build: > All done. > cd bsd_amd64_compiler2/fastdebug && ./test_gamma > openjdk full version "1.7.0-internal-stephen_2011_10_22_22_58-b00" > Error occurred during initialization of VM > Unable to load native library: dlopen(/Users/stephen/dev/java/src/mlvm/sources/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/libjava.dylib, 1): image not found > ./test_gamma: line 13: ./gamma: No such file or directory Same problem here (XCode 4 and OpenJDK 7 from macosx-port) ;( From mroos at roos.com Thu Nov 3 14:27:57 2011 From: mroos at roos.com (Mark Roos) Date: Thu, 3 Nov 2011 14:27:57 -0700 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: >From Henri All done. cd bsd_amd64_compiler2/fastdebug && ./test_gamma openjdk full version "1.7.0-b147-20110923" Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object I get the noclassdef found error when I run my code tests using b147 due to a bug in the vm. So it may not be the build that is at fault for this one. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111103/8c447946/attachment.html From henri.gomez at gmail.com Thu Nov 3 16:43:36 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 4 Nov 2011 00:43:36 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: <780D55C6-6604-4A61-A060-F59F13300FAD@gmail.com> I didn't get gamma built. I see your OpenJDK is an old one. From bsd-port ? Are you using XCode 4 or previous ? Le 3 nov. 2011 ? 22:27, Mark Roos a ?crit : > From Henri > > All done. > cd bsd_amd64_compiler2/fastdebug && ./test_gamma > openjdk full version "1.7.0-b147-20110923" > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/Object > > > I get the noclassdef found error when I run my code tests using b147 due to a bug > in the vm. So it may not be the build that is at fault for this one. > > regards > mark > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111104/d0537278/attachment.html From john.r.rose at oracle.com Thu Nov 3 22:29:25 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 04 Nov 2011 05:29:25 +0000 Subject: hg: mlvm/mlvm/hotspot: mac-tweaks: work around MACOSX_PORT-214; also guard meth-lazy Message-ID: <20111104052925.C66E847238@hg.openjdk.java.net> Changeset: 6cfc18c8992a Author: jrose Date: 2011-11-03 22:29 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/6cfc18c8992a mac-tweaks: work around MACOSX_PORT-214; also guard meth-lazy ! mac-tweaks.patch ! series From john.r.rose at oracle.com Thu Nov 3 22:54:45 2011 From: john.r.rose at oracle.com (John Rose) Date: Thu, 3 Nov 2011 22:54:45 -0700 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: Recent changes in hsx/hotspot have destabilized the build on mac. I just pushed another workaround here: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/mac-tweaks.patch The buildtree.make change fixes the failure Henri saw. (Or you can add "ALWAYS_PASS_TEST_GAMMA=true" to the build script settings.) -- John P.S. I tried a build with llvm-gcc and got sporadic bus errors. Went back to gcc-4.0 and things got quieter. On Nov 3, 2011, at 12:53 AM, Henri Gomez wrote: > Hi to all, > > I'd like to provide OpenJDK 8 with MLVM to OS/X users as I'm doing for > month with OpenJDK 7 on http://code.google.com/p/openjdk-osx-build/. > > I'm trying to build it using Stephen scripts > (https://gist.github.com/243072) for now but I still can't get it From john.r.rose at oracle.com Fri Nov 4 01:34:08 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 04 Nov 2011 08:34:08 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: pass MethodHandlesTests Message-ID: <20111104083409.2135A4723A@hg.openjdk.java.net> Changeset: 4e9ab8e78d56 Author: jrose Date: 2011-11-04 01:34 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4e9ab8e78d56 meth-lazy: pass MethodHandlesTests ! meth-lazy.patch From john.r.rose at oracle.com Fri Nov 4 01:34:23 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 04 Nov 2011 08:34:23 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: pass MethodHandlesTests Message-ID: <20111104083424.122ED4723B@hg.openjdk.java.net> Changeset: bb482cc165c8 Author: jrose Date: 2011-11-04 01:34 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/bb482cc165c8 meth-lazy: pass MethodHandlesTests ! meth-lazy.patch From henri.gomez at gmail.com Fri Nov 4 01:47:22 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 4 Nov 2011 09:47:22 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: 2011/11/4 John Rose : > Recent changes in hsx/hotspot have destabilized the build on mac. ?I just pushed another workaround here: > > ?http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/mac-tweaks.patch > > The buildtree.make change fixes the failure Henri saw. ?(Or you can add "ALWAYS_PASS_TEST_GAMMA=true" to the build script settings.) > > -- John > > P.S. ?I tried a build with llvm-gcc and got sporadic bus errors. ?Went back to gcc-4.0 and things got quieter. Seems to works better :) One built done with gcc/g++ 4.0 and another with gcc/g++ 4.2, not tried yet with llvm's From stephen.bannasch at deanbrook.org Fri Nov 4 07:16:57 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Fri, 4 Nov 2011 10:16:57 -0400 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: Yes, works now for me using gcc 4.0, thanks. New build available here: http://www.concord.org/~sbannasch/mlvm/java-1.8.0-internal-mlvm-2011_11_04.tar.gz pass all jdk/test/java/lang/invoke tests as well as jdk/test/java/dyn/CoroutineTest.java From henri.gomez at gmail.com Fri Nov 4 08:30:35 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 4 Nov 2011 16:30:35 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: > Yes, works now for me using gcc 4.0, thanks. > > New build available here: > http://www.concord.org/~sbannasch/mlvm/java-1.8.0-internal-mlvm-2011_11_04.tar.gz > > pass all jdk/test/java/lang/invoke tests as well as jdk/test/java/dyn/CoroutineTest.java I'll try some build manually and if nothing get broken, I'll provide packages in DMG format also. From headius at headius.com Fri Nov 4 15:59:12 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 4 Nov 2011 19:59:12 -0300 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: First: thank you thank you thank you for adding JDK 8 builds. It will be so much nicer than testing in vbox. Second: Does OpenJDK 7 build with LLVM? Does it work on NaCl? :-) - Charlie (mobile) On Nov 3, 2011 4:53 AM, "Henri Gomez" wrote: > > Hi to all, > > I'd like to provide OpenJDK 8 with MLVM to OS/X users as I'm doing for > month with OpenJDK 7 on http://code.google.com/p/openjdk-osx-build/. > > I'm trying to build it using Stephen scripts > (https://gist.github.com/243072) for now but I still can't get it > built : > > > /Users/henri/Downloads/openjdk8/mlvm/sources/ALT_COMPILER_PATH/g++ > -m64 -Wl,-install_name, at rpath/libjvm.dylib -dynamiclib > -compatibility_version 1.0.0 -current_version 1.0.0 -fPIC > \ > -Xlinker -rpath -Xlinker @loader_path/. -Xlinker -rpath > -Xlinker @loader_path/.. -Xlinker -install_name -Xlinker > @rpath/libjvm.dylib -o libjvm.dylib abstractCompiler.o accessFlags.o > ad_x86_64.o ad_x86_64_clone.o ad_x86_64_expand.o ad_x86_64_format.o > ad_x86_64_gen.o ad_x86_64_misc.o ad_x86_64_peephole.o > ad_x86_64_pipeline.o adaptiveSizePolicy.o addnode.o > adjoiningGenerations.o adjoiningVirtualSpaces.o > advancedThresholdPolicy.o ageTable.o allocation.o allocationStats.o > aprofiler.o arguments.o array.o arrayKlass.o arrayKlassKlass.o > arrayOop.o asPSOldGen.o asPSYoungGen.o asParNewGeneration.o > assembler.o assembler_bsd_x86.o assembler_x86.o atomic.o > attachListener.o attachListener_bsd.o barrierSet.o basicLock.o > bcEscapeAnalyzer.o biasedLocking.o binaryTreeDictionary.o bitMap.o > block.o blockOffsetTable.o bsd_x86_64.o buildOopMap.o bytecode.o > bytecodeHistogram.o bytecodeInfo.o bytecodeInterpreter.o > bytecodeInterpreterWithChecks.o bytecodeInterpreter_x86.o > bytecodeStream.o bytecodeTracer.o bytecodes.o bytecodes_x86.o > c1_CFGPrinter.o c1_Canonicalizer.o c1_CodeStubs_x86.o c1_Compilation.o > c1_Compiler.o c1_Defs.o c1_FpuStackSim_x86.o c1_FrameMap.o > c1_FrameMap_x86.o c1_GraphBuilder.o c1_IR.o c1_Instruction.o > c1_InstructionPrinter.o c1_LIR.o c1_LIRAssembler.o > c1_LIRAssembler_x86.o c1_LIRGenerator.o c1_LIRGenerator_x86.o > c1_LinearScan.o c1_LinearScan_x86.o c1_MacroAssembler_x86.o > c1_Optimizer.o c1_Runtime1.o c1_Runtime1_x86.o c1_ValueMap.o > c1_ValueSet.o c1_ValueStack.o c1_ValueType.o c1_globals.o c2_globals.o > c2_init_x86.o c2compiler.o cSpaceCounters.o callGenerator.o callnode.o > cardTableExtension.o cardTableModRefBS.o cardTableRS.o cfgnode.o > chaitin.o chaitin_bsd.o ciArray.o ciArrayKlass.o ciCPCache.o > ciCallSite.o ciConstant.o ciConstantPoolCache.o ciEnv.o > ciExceptionHandler.o ciField.o ciFlags.o ciInstance.o > ciInstanceKlass.o ciInstanceKlassKlass.o ciKlass.o ciKlassKlass.o > ciMethod.o ciMethodBlocks.o ciMethodData.o ciMethodHandle.o > ciMethodKlass.o ciNullObject.o ciObjArray.o ciObjArrayKlass.o > ciObjArrayKlassKlass.o ciObject.o ciObjectFactory.o ciSignature.o > ciStreams.o ciSymbol.o ciType.o ciTypeArray.o ciTypeArrayKlass.o > ciTypeArrayKlassKlass.o ciTypeFlow.o ciUtilities.o classFileError.o > classFileParser.o classFileStream.o classLoader.o > classLoadingService.o classes.o classify.o cmsAdaptiveSizePolicy.o > cmsCollectorPolicy.o cmsGCAdaptivePolicyCounters.o cmsLockVerifier.o > cmsPermGen.o coalesce.o codeBlob.o codeBuffer.o codeCache.o > collectedHeap.o collectionSetChooser.o collectorCounters.o > collectorPolicy.o compactibleFreeListSpace.o compactingPermGenGen.o > compilationPolicy.o compile.o compileBroker.o compileLog.o > compiledIC.o compiledICHolderKlass.o compiledICHolderOop.o > compilerOracle.o compressedStream.o concurrentG1Refine.o > concurrentG1RefineThread.o concurrentGCThread.o concurrentMark.o > concurrentMarkSweepGeneration.o concurrentMarkSweepThread.o > concurrentMarkThread.o connode.o constMethodKlass.o constMethodOop.o > constantPoolKlass.o constantPoolOop.o constantTag.o copy.o coroutine.o > cpCacheKlass.o cpCacheOop.o cppInterpreter.o cppInterpreter_x86.o > debug.o debugInfo.o debugInfoRec.o debug_x86.o decoder.o decoder_bsd.o > defNewGeneration.o deoptimization.o depChecker_x86.o dependencies.o > dfa_x86_64.o dict.o dictionary.o dirtyCardQueue.o disassembler.o > divnode.o doCall.o domgraph.o dtraceAttacher.o dtraceJSDT.o > dtraceJSDT_bsd.o dump.o dump_x86_64.o elfFile.o elfStringTable.o > elfSymbolTable.o errorReporter.o escape.o events.o evmCompat.o > exceptionHandlerTable.o exceptions.o fieldDescriptor.o fieldType.o > filemap.o forte.o fprofiler.o frame.o frame_x86.o > freeBlockDictionary.o freeChunk.o freeList.o g1AllocRegion.o > g1BlockOffsetTable.o g1CollectedHeap.o g1CollectorPolicy.o > g1ErgoVerbose.o g1HRPrinter.o g1MMUTracker.o g1MarkSweep.o > g1MemoryPool.o g1MonitoringSupport.o g1RemSet.o > g1SATBCardTableModRefBS.o g1_globals.o gSpaceCounters.o > gcAdaptivePolicyCounters.o gcCause.o gcLocker.o gcNotifier.o > gcPolicyCounters.o gcStats.o gcTaskManager.o gcTaskThread.o gcUtil.o > gcm.o genCollectedHeap.o genMarkSweep.o genRemSet.o generateOopMap.o > generateOptoStub.o generation.o generationCounters.o generationSpec.o > globalDefinitions.o globals.o graphKit.o growableArray.o > hSpaceCounters.o handles.o hashtable.o heap.o heapDumper.o > heapInspection.o heapRegion.o heapRegionRemSet.o heapRegionSeq.o > heapRegionSet.o heapRegionSets.o histogram.o icBuffer.o icBuffer_x86.o > icache.o icache_x86.o idealGraphPrinter.o idealKit.o ifg.o ifnode.o > immutableSpace.o indexSet.o init.o instanceKlass.o > instanceKlassKlass.o instanceMirrorKlass.o instanceOop.o > instanceRefKlass.o intHisto.o interfaceSupport.o interp_masm_x86_64.o > interpreter.o interpreterRT_x86_64.o interpreterRuntime.o > interpreter_x86_64.o invocationCounter.o iterator.o java.o > javaAssertions.o javaCalls.o javaClasses.o jni.o jniCheck.o > jniFastGetField.o jniFastGetField_x86_64.o jniHandles.o > jniPeriodicChecker.o jvm.o jvm_bsd.o jvmtiClassFileReconstituter.o > jvmtiCodeBlobEvents.o jvmtiEnter.o jvmtiEnterTrace.o jvmtiEnv.o > jvmtiEnvBase.o jvmtiEnvThreadState.o jvmtiEventController.o > jvmtiExport.o jvmtiExtensions.o jvmtiGetLoadedClasses.o jvmtiImpl.o > jvmtiManageCapabilities.o jvmtiRawMonitor.o jvmtiRedefineClasses.o > jvmtiTagMap.o jvmtiThreadState.o jvmtiTrace.o jvmtiUtil.o klass.o > klassKlass.o klassOop.o klassVtable.o lcm.o library_call.o > linkResolver.o live.o loaderConstraints.o location.o locknode.o > loopPredicate.o loopTransform.o loopUnswitch.o loopnode.o loopopts.o > lowMemoryDetector.o machnode.o macro.o management.o markOop.o > markSweep.o matcher.o memRegion.o memnode.o memoryManager.o > memoryPool.o memoryService.o memprofiler.o methodComparator.o > methodDataKlass.o methodDataOop.o methodHandleWalk.o methodHandles.o > methodHandles_x86.o methodKlass.o methodLiveness.o methodOop.o > monitorChunk.o mulnode.o multnode.o mutableNUMASpace.o mutableSpace.o > mutex.o mutexLocker.o mutex_bsd.o nativeInst_x86.o nativeLookup.o > nmethod.o node.o numberSeq.o objArrayKlass.o objArrayKlassKlass.o > objArrayOop.o objectMonitor.o objectStartArray.o oop.o oopFactory.o > oopMap.o oopMapCache.o oopRecorder.o oopsHierarchy.o opcodes.o > orderAccess.o os.o osThread.o osThread_bsd.o os_bsd.o os_bsd_x86.o > os_posix.o ostream.o output.o parCardTableModRefBS.o > parGCAllocBuffer.o parMarkBitMap.o parNewGeneration.o > parallelScavengeHeap.o park.o parse1.o parse2.o parse3.o parseHelper.o > pcDesc.o pcTasks.o perf.o perfData.o perfMemory.o perfMemory_bsd.o > permGen.o phase.o phaseX.o placeholders.o port.o postaloc.o > preserveException.o privilegedStack.o promotionInfo.o > psAdaptiveSizePolicy.o psCompactionManager.o > psGCAdaptivePolicyCounters.o psGenerationCounters.o psMarkSweep.o > psMarkSweepDecorator.o psMemoryPool.o psOldGen.o psParallelCompact.o > psPermGen.o psPromotionLAB.o psPromotionManager.o psScavenge.o > psTasks.o psVirtualspace.o psYoungGen.o ptrQueue.o quickSort.o > referencePolicy.o referenceProcessor.o reflection.o reflectionUtils.o > reg_split.o regalloc.o register.o register_definitions_x86.o > register_x86.o regmask.o relocInfo.o relocInfo_x86.o relocator.o > resolutionErrors.o resourceArea.o restore.o rewriter.o rframe.o > rootnode.o runtime.o runtimeService.o runtime_x86_64.o safepoint.o > satbQueue.o scopeDesc.o serialize.o serviceThread.o set.o sharedHeap.o > sharedRuntime.o sharedRuntimeTrans.o sharedRuntimeTrig.o > sharedRuntime_x86_64.o signature.o simpleThresholdPolicy.o sizes.o > space.o spaceCounters.o spaceDecorator.o sparsePRT.o > specialized_oop_closures.o split_if.o stackMapFrame.o stackMapTable.o > stackValue.o stackValueCollection.o statSampler.o stringopts.o > stubCodeGenerator.o stubGenerator_x86_64.o stubRoutines.o > stubRoutines_bsd.o stubRoutines_x86_64.o stubs.o subnode.o superword.o > survRateGroup.o sweeper.o symbol.o symbolTable.o synchronizer.o > systemDictionary.o task.o taskqueue.o templateInterpreter.o > templateInterpreter_x86_64.o templateTable.o templateTable_x86_64.o > tenuredGeneration.o thread.o threadCritical_bsd.o threadLS_bsd_x -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111104/44ef8dfa/attachment.html From headius at headius.com Sat Nov 5 09:53:00 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 5 Nov 2011 13:53:00 -0300 Subject: Unusual warnings during buid against latest stephenb mlvm Message-ID: Just thought I'd leave these here: [apt] Warning: Handler @28107368 takes mixed loaded/unloaded exceptions in [apt] virtual jobject java.lang.Class.getEnumConstantsShared() [apt] Warning: Handler @28107368 takes mixed loaded/unloaded exceptions in [apt] virtual jobject java.lang.Class.getEnumConstantsShared() [apt] Warning: Handler @28107368 takes mixed loaded/unloaded exceptions in [apt] virtual jobject java.lang.Class.getEnumConstantsShared() [apt] Warning: Handler @28107368 takes mixed loaded/unloaded exceptions in [apt] virtual jobject java.lang.Class.getEnumConstantsShared() [apt] Warning: Handler @28107368 takes mixed loaded/unloaded exceptions in [apt] virtual jobject java.lang.Class.getEnumConstantsShared() Otherwise the latest build is screaming fast...exciting! - Charlie From henri.gomez at gmail.com Sat Nov 5 13:50:05 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Sat, 5 Nov 2011 21:50:05 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: Thanks. Yes, OpenJDK 7 is using llvm gcc/g++ Le 4 nov. 2011 ? 23:59, Charles Oliver Nutter a ?crit : > First: thank you thank you thank you for adding JDK 8 builds. It will be so much nicer than testing in vbox. > > Second: Does OpenJDK 7 build with LLVM? Does it work on NaCl? :-) > > - Charlie (mobile) > On Nov 3, 2011 4:53 AM, "Henri Gomez" wrote: > > > > Hi to all, > > > > I'd like to provide OpenJDK 8 with MLVM to OS/X users as I'm doing for > > month with OpenJDK 7 on http://code.google.com/p/openjdk-osx-build/. > > > > I'm trying to build it using Stephen scripts > > (https://gist.github.com/243072) for now but I still can't get it > > built : > > > > > > /Users/henri/Downloads/openjdk8/mlvm/sources/ALT_COMPILER_PATH/g++ > > -m64 -Wl,-install_name, at rpath/libjvm.dylib -dynamiclib > > -compatibility_version 1.0.0 -current_version 1.0.0 -fPIC > > \ > > -Xlinker -rpath -Xlinker @loader_path/. -Xlinker -rpath > > -Xlinker @loader_path/.. -Xlinker -install_name -Xlinker > > @rpath/libjvm.dylib -o libjvm.dylib abstractCompiler.o accessFlags.o > > ad_x86_64.o ad_x86_64_clone.o ad_x86_64_expand.o ad_x86_64_format.o > > ad_x86_64_gen.o ad_x86_64_misc.o ad_x86_64_peephole.o > > ad_x86_64_pipeline.o adaptiveSizePolicy.o addnode.o > > adjoiningGenerations.o adjoiningVirtualSpaces.o > > advancedThresholdPolicy.o ageTable.o allocation.o allocationStats.o > > aprofiler.o arguments.o array.o arrayKlass.o arrayKlassKlass.o > > arrayOop.o asPSOldGen.o asPSYoungGen.o asParNewGeneration.o > > assembler.o assembler_bsd_x86.o assembler_x86.o atomic.o > > attachListener.o attachListener_bsd.o barrierSet.o basicLock.o > > bcEscapeAnalyzer.o biasedLocking.o binaryTreeDictionary.o bitMap.o > > block.o blockOffsetTable.o bsd_x86_64.o buildOopMap.o bytecode.o > > bytecodeHistogram.o bytecodeInfo.o bytecodeInterpreter.o > > bytecodeInterpreterWithChecks.o bytecodeInterpreter_x86.o > > bytecodeStream.o bytecodeTracer.o bytecodes.o bytecodes_x86.o > > c1_CFGPrinter.o c1_Canonicalizer.o c1_CodeStubs_x86.o c1_Compilation.o > > c1_Compiler.o c1_Defs.o c1_FpuStackSim_x86.o c1_FrameMap.o > > c1_FrameMap_x86.o c1_GraphBuilder.o c1_IR.o c1_Instruction.o > > c1_InstructionPrinter.o c1_LIR.o c1_LIRAssembler.o > > c1_LIRAssembler_x86.o c1_LIRGenerator.o c1_LIRGenerator_x86.o > > c1_LinearScan.o c1_LinearScan_x86.o c1_MacroAssembler_x86.o > > c1_Optimizer.o c1_Runtime1.o c1_Runtime1_x86.o c1_ValueMap.o > > c1_ValueSet.o c1_ValueStack.o c1_ValueType.o c1_globals.o c2_globals.o > > c2_init_x86.o c2compiler.o cSpaceCounters.o callGenerator.o callnode.o > > cardTableExtension.o cardTableModRefBS.o cardTableRS.o cfgnode.o > > chaitin.o chaitin_bsd.o ciArray.o ciArrayKlass.o ciCPCache.o > > ciCallSite.o ciConstant.o ciConstantPoolCache.o ciEnv.o > > ciExceptionHandler.o ciField.o ciFlags.o ciInstance.o > > ciInstanceKlass.o ciInstanceKlassKlass.o ciKlass.o ciKlassKlass.o > > ciMethod.o ciMethodBlocks.o ciMethodData.o ciMethodHandle.o > > ciMethodKlass.o ciNullObject.o ciObjArray.o ciObjArrayKlass.o > > ciObjArrayKlassKlass.o ciObject.o ciObjectFactory.o ciSignature.o > > ciStreams.o ciSymbol.o ciType.o ciTypeArray.o ciTypeArrayKlass.o > > ciTypeArrayKlassKlass.o ciTypeFlow.o ciUtilities.o classFileError.o > > classFileParser.o classFileStream.o classLoader.o > > classLoadingService.o classes.o classify.o cmsAdaptiveSizePolicy.o > > cmsCollectorPolicy.o cmsGCAdaptivePolicyCounters.o cmsLockVerifier.o > > cmsPermGen.o coalesce.o codeBlob.o codeBuffer.o codeCache.o > > collectedHeap.o collectionSetChooser.o collectorCounters.o > > collectorPolicy.o compactibleFreeListSpace.o compactingPermGenGen.o > > compilationPolicy.o compile.o compileBroker.o compileLog.o > > compiledIC.o compiledICHolderKlass.o compiledICHolderOop.o > > compilerOracle.o compressedStream.o concurrentG1Refine.o > > concurrentG1RefineThread.o concurrentGCThread.o concurrentMark.o > > concurrentMarkSweepGeneration.o concurrentMarkSweepThread.o > > concurrentMarkThread.o connode.o constMethodKlass.o constMethodOop.o > > constantPoolKlass.o constantPoolOop.o constantTag.o copy.o coroutine.o > > cpCacheKlass.o cpCacheOop.o cppInterpreter.o cppInterpreter_x86.o > > debug.o debugInfo.o debugInfoRec.o debug_x86.o decoder.o decoder_bsd.o > > defNewGeneration.o deoptimization.o depChecker_x86.o dependencies.o > > dfa_x86_64.o dict.o dictionary.o dirtyCardQueue.o disassembler.o > > divnode.o doCall.o domgraph.o dtraceAttacher.o dtraceJSDT.o > > dtraceJSDT_bsd.o dump.o dump_x86_64.o elfFile.o elfStringTable.o > > elfSymbolTable.o errorReporter.o escape.o events.o evmCompat.o > > exceptionHandlerTable.o exceptions.o fieldDescriptor.o fieldType.o > > filemap.o forte.o fprofiler.o frame.o frame_x86.o > > freeBlockDictionary.o freeChunk.o freeList.o g1AllocRegion.o > > g1BlockOffsetTable.o g1CollectedHeap.o g1CollectorPolicy.o > > g1ErgoVerbose.o g1HRPrinter.o g1MMUTracker.o g1MarkSweep.o > > g1MemoryPool.o g1MonitoringSupport.o g1RemSet.o > > g1SATBCardTableModRefBS.o g1_globals.o gSpaceCounters.o > > gcAdaptivePolicyCounters.o gcCause.o gcLocker.o gcNotifier.o > > gcPolicyCounters.o gcStats.o gcTaskManager.o gcTaskThread.o gcUtil.o > > gcm.o genCollectedHeap.o genMarkSweep.o genRemSet.o generateOopMap.o > > generateOptoStub.o generation.o generationCounters.o generationSpec.o > > globalDefinitions.o globals.o graphKit.o growableArray.o > > hSpaceCounters.o handles.o hashtable.o heap.o heapDumper.o > > heapInspection.o heapRegion.o heapRegionRemSet.o heapRegionSeq.o > > heapRegionSet.o heapRegionSets.o histogram.o icBuffer.o icBuffer_x86.o > > icache.o icache_x86.o idealGraphPrinter.o idealKit.o ifg.o ifnode.o > > immutableSpace.o indexSet.o init.o instanceKlass.o > > instanceKlassKlass.o instanceMirrorKlass.o instanceOop.o > > instanceRefKlass.o intHisto.o interfaceSupport.o interp_masm_x86_64.o > > interpreter.o interpreterRT_x86_64.o interpreterRuntime.o > > interpreter_x86_64.o invocationCounter.o iterator.o java.o > > javaAssertions.o javaCalls.o javaClasses.o jni.o jniCheck.o > > jniFastGetField.o jniFastGetField_x86_64.o jniHandles.o > > jniPeriodicChecker.o jvm.o jvm_bsd.o jvmtiClassFileReconstituter.o > > jvmtiCodeBlobEvents.o jvmtiEnter.o jvmtiEnterTrace.o jvmtiEnv.o > > jvmtiEnvBase.o jvmtiEnvThreadState.o jvmtiEventController.o > > jvmtiExport.o jvmtiExtensions.o jvmtiGetLoadedClasses.o jvmtiImpl.o > > jvmtiManageCapabilities.o jvmtiRawMonitor.o jvmtiRedefineClasses.o > > jvmtiTagMap.o jvmtiThreadState.o jvmtiTrace.o jvmtiUtil.o klass.o > > klassKlass.o klassOop.o klassVtable.o lcm.o library_call.o > > linkResolver.o live.o loaderConstraints.o location.o locknode.o > > loopPredicate.o loopTransform.o loopUnswitch.o loopnode.o loopopts.o > > lowMemoryDetector.o machnode.o macro.o management.o markOop.o > > markSweep.o matcher.o memRegion.o memnode.o memoryManager.o > > memoryPool.o memoryService.o memprofiler.o methodComparator.o > > methodDataKlass.o methodDataOop.o methodHandleWalk.o methodHandles.o > > methodHandles_x86.o methodKlass.o methodLiveness.o methodOop.o > > monitorChunk.o mulnode.o multnode.o mutableNUMASpace.o mutableSpace.o > > mutex.o mutexLocker.o mutex_bsd.o nativeInst_x86.o nativeLookup.o > > nmethod.o node.o numberSeq.o objArrayKlass.o objArrayKlassKlass.o > > objArrayOop.o objectMonitor.o objectStartArray.o oop.o oopFactory.o > > oopMap.o oopMapCache.o oopRecorder.o oopsHierarchy.o opcodes.o > > orderAccess.o os.o osThread.o osThread_bsd.o os_bsd.o os_bsd_x86.o > > os_posix.o ostream.o output.o parCardTableModRefBS.o > > parGCAllocBuffer.o parMarkBitMap.o parNewGeneration.o > > parallelScavengeHeap.o park.o parse1.o parse2.o parse3.o parseHelper.o > > pcDesc.o pcTasks.o perf.o perfData.o perfMemory.o perfMemory_bsd.o > > permGen.o phase.o phaseX.o placeholders.o port.o postaloc.o > > preserveException.o privilegedStack.o promotionInfo.o > > psAdaptiveSizePolicy.o psCompactionManager.o > > psGCAdaptivePolicyCounters.o psGenerationCounters.o psMarkSweep.o > > psMarkSweepDecorator.o psMemoryPool.o psOldGen.o psParallelCompact.o > > psPermGen.o psPromotionLAB.o psPromotionManager.o psScavenge.o > > psTasks.o psVirtualspace.o psYoungGen.o ptrQueue.o quickSort.o > > referencePolicy.o referenceProcessor.o reflection.o reflectionUtils.o > > reg_split.o regalloc.o register.o register_definitions_x86.o > > register_x86.o regmask.o relocInfo.o relocInfo_x86.o relocator.o > > resolutionErrors.o resourceArea.o restore.o rewriter.o rframe.o > > rootnode.o runtime.o runtimeService.o runtime_x86_64.o safepoint.o > > satbQueue.o scopeDesc.o serialize.o serviceThread.o set.o sharedHeap.o > > sharedRuntime.o sharedRuntimeTrans.o sharedRuntimeTrig.o > > sharedRuntime_x86_64.o signature.o simpleThresholdPolicy.o sizes.o > > space.o spaceCounters.o spaceDecorator.o sparsePRT.o > > specialized_oop_closures.o split_if.o stackMapFrame.o stackMapTable.o > > stackValue.o stackValueCollection.o statSampler.o stringopts.o > > stubCodeGenerator.o stubGenerator_x86_64.o stubRoutines.o > > stubRoutines_bsd.o stubRoutines_x86_64.o stubs.o subnode.o superword.o > > survRateGroup.o sweeper.o symbol.o symbolTable.o synchronizer.o > > systemDictionary.o task.o taskqueue.o templateInterpreter.o > > templateInterpreter_x86_64.o templateTable.o templateTable_x86_64.o > > tenuredGeneration.o thread.o threadCritical_bsd.o threadLS_bsd_x > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111105/9a5dc846/attachment.html From headius at headius.com Sat Nov 5 15:24:31 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 5 Nov 2011 19:24:31 -0300 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: On Sat, Nov 5, 2011 at 5:50 PM, Henri Gomez wrote: > Thanks. > Yes, OpenJDK 7 is using llvm gcc/g++ Awesome...now I'm really curious about the potential for OpenJDK on Native Client via LLVM. - Charlie From henri.gomez at gmail.com Sun Nov 6 02:39:00 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 6 Nov 2011 11:39:00 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: Charles For OpenJDK 8 build/package for OS/X, you told me FASTDEBUG slow down startup stuff. Do you want me to disable it in OSX build/package ? 2011/11/5 Charles Oliver Nutter : > On Sat, Nov 5, 2011 at 5:50 PM, Henri Gomez wrote: >> Thanks. >> Yes, OpenJDK 7 is using llvm gcc/g++ > > Awesome...now I'm really curious about the potential for OpenJDK on > Native Client via LLVM. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From headius at headius.com Sun Nov 6 06:26:54 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 6 Nov 2011 11:26:54 -0300 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: You've already pushed a package, but yeah, for me fastdebug is always slower...not by a lot, but for end-users trying out JRuby I want to make sure they're running something as close to a normal release as possible. - Charlie On Sun, Nov 6, 2011 at 7:39 AM, Henri Gomez wrote: > Charles > > For OpenJDK 8 build/package for OS/X, you told me FASTDEBUG slow down > startup stuff. > Do you want me to disable it in OSX build/package ? > > > 2011/11/5 Charles Oliver Nutter : >> On Sat, Nov 5, 2011 at 5:50 PM, Henri Gomez wrote: >>> Thanks. >>> Yes, OpenJDK 7 is using llvm gcc/g++ >> >> Awesome...now I'm really curious about the potential for OpenJDK on >> Native Client via LLVM. >> >> - Charlie >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From henri.gomez at gmail.com Sun Nov 6 09:56:49 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 6 Nov 2011 18:56:49 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: Message-ID: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Fastdebug could be disabled. Did it change many things inside VM is fastdebug is not used ? Le 6 nov. 2011 ? 15:26, Charles Oliver Nutter a ?crit : > You've already pushed a package, but yeah, for me fastdebug is always > slower...not by a lot, but for end-users trying out JRuby I want to > make sure they're running something as close to a normal release as > possible. > > - Charlie > > On Sun, Nov 6, 2011 at 7:39 AM, Henri Gomez wrote: >> Charles >> >> For OpenJDK 8 build/package for OS/X, you told me FASTDEBUG slow down >> startup stuff. >> Do you want me to disable it in OSX build/package ? >> >> >> 2011/11/5 Charles Oliver Nutter : >>> On Sat, Nov 5, 2011 at 5:50 PM, Henri Gomez wrote: >>>> Thanks. >>>> Yes, OpenJDK 7 is using llvm gcc/g++ >>> >>> Awesome...now I'm really curious about the potential for OpenJDK on >>> Native Client via LLVM. >>> >>> - Charlie >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From henri.gomez at gmail.com Sun Nov 6 13:12:09 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 6 Nov 2011 22:12:09 +0100 Subject: Coro patch Message-ID: Hi to all, I'm looking for Coro patch by Lukas Stadler, any body knows where I can find it ? From lukas.stadler at jku.at Sun Nov 6 13:21:40 2011 From: lukas.stadler at jku.at (Lukas Stadler) Date: Sun, 6 Nov 2011 22:21:40 +0100 Subject: Coro patch In-Reply-To: References: Message-ID: <67688E8B-279A-4E32-872E-6303F5D288DA@jku.at> Yes, I do :-) The patch is part of the mlvm patch repository: http://hg.openjdk.java.net/mlvm/mlvm (see instructions at http://wikis.sun.com/display/mlvm/Home) ... but if you don't want to build the jdk yourself there's a pre-built binary at: http://ssw.jku.at/General/Staff/LS/coro/ - Lukas On Nov 6, 2011, at 22:12 , Henri Gomez wrote: > Hi to all, > > I'm looking for Coro patch by Lukas Stadler, any body knows where I can find it ? > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111106/5e83c6f4/attachment.html From henri.gomez at gmail.com Sun Nov 6 13:35:18 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 6 Nov 2011 22:35:18 +0100 Subject: Coro patch In-Reply-To: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> Message-ID: Ok, I get them and coro is included in OpenJDK 8 from openjdk-osx-build 2011/11/6 Henri Gomez : > > > Le 6 nov. 2011 ? 22:12, Henri Gomez a ?crit : > >> Hi to all, >> >> I'm looking for Coro patch by Lukas Stadler, any body knows where I can find it ? > > More on this, I found patch here (http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ca450b9f8b56), but wondering if it's allready applied to trunk or in some patch area ? > > Thanks for your help/advices From headius at headius.com Sun Nov 6 15:18:15 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 6 Nov 2011 20:18:15 -0300 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> Message-ID: Ok, bug report time! :) It looks like it's crashing again once Hotspot JITs. This works: jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 100 100 But this doesn't: jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 1000 100 Here's the console output, and I've attached the log. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/frame_x86.cpp:312 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/Users/henri/Documents/jenkins/data/jobs/openjdk-1.8-bsdport-x86_64/workspace/sources/hotspot/src/cpu/x86/vm/frame_x86.cpp:312), pid=21511, tid=4341268480 # assert(sp() <= result + _displacement) failed: monitor end should be above the stack pointer # # JRE version: 8.0 # Java VM: OpenJDK 64-Bit Server VM (23.0-b03-fastdebug mixed mode bsd-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/headius/projects/jruby/hs_err_pid21511.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 4341268480 Dumping core ... Abort trap - Charlie On Sun, Nov 6, 2011 at 6:35 PM, Henri Gomez wrote: > Ok, I get them and coro is included in OpenJDK 8 from openjdk-osx-build > > 2011/11/6 Henri Gomez : >> >> >> Le 6 nov. 2011 ? 22:12, Henri Gomez a ?crit : >> >>> Hi to all, >>> >>> I'm looking for Coro patch by Lukas Stadler, any body knows where I can find it ? >> >> More on this, I found patch here (http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ca450b9f8b56), but wondering if it's allready applied to trunk or in some patch area ? >> >> Thanks for your help/advices > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid21511.log Type: application/octet-stream Size: 7473 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111106/70e2f26d/hs_err_pid21511.log From henri.gomez at gmail.com Sun Nov 6 15:24:37 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 7 Nov 2011 00:24:37 +0100 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> Message-ID: Note about the build env for this package. Done under OSX 10.6.8, XCode 4, gcc/g++ 4.2 (not llvm 4.2). 2011/11/7 Charles Oliver Nutter : > Ok, bug report time! :) > > It looks like it's crashing again once Hotspot JITs. > > This works: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 100 100 > > But this doesn't: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 1000 100 > > Here's the console output, and I've attached the log. > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: ?SuppressErrorAt=/frame_x86.cpp:312 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # ?Internal Error > (/Users/henri/Documents/jenkins/data/jobs/openjdk-1.8-bsdport-x86_64/workspace/sources/hotspot/src/cpu/x86/vm/frame_x86.cpp:312), > pid=21511, tid=4341268480 > # ?assert(sp() <= result + _displacement) failed: monitor end should > be above the stack pointer > # > # JRE version: 8.0 > # Java VM: OpenJDK 64-Bit Server VM (23.0-b03-fastdebug mixed mode > bsd-amd64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/headius/projects/jruby/hs_err_pid21511.log > # > # If you would like to submit a bug report, please visit: > # ? http://bugreport.sun.com/bugreport/crash.jsp > # > Current thread is 4341268480 > Dumping core ... > Abort trap > > - Charlie > > On Sun, Nov 6, 2011 at 6:35 PM, Henri Gomez wrote: >> Ok, I get them and coro is included in OpenJDK 8 from openjdk-osx-build >> >> 2011/11/6 Henri Gomez : >>> >>> >>> Le 6 nov. 2011 ? 22:12, Henri Gomez a ?crit : >>> >>>> Hi to all, >>>> >>>> I'm looking for Coro patch by Lukas Stadler, any body knows where I can find it ? >>> >>> More on this, I found patch here (http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ca450b9f8b56), but wondering if it's allready applied to trunk or in some patch area ? >>> >>> Thanks for your help/advices >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > From headius at headius.com Sun Nov 6 17:05:53 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Sun, 6 Nov 2011 22:05:53 -0300 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: Not much. There are a few monitoring/debugging flags that won't work but they aren't anything a typical user wants to use. The installed package would be better as a release build. - Charlie (mobile) On Nov 6, 2011 2:57 PM, "Henri Gomez" wrote: > Fastdebug could be disabled. > > Did it change many things inside VM is fastdebug is not used ? > > Le 6 nov. 2011 ? 15:26, Charles Oliver Nutter a > ?crit : > > > You've already pushed a package, but yeah, for me fastdebug is always > > slower...not by a lot, but for end-users trying out JRuby I want to > > make sure they're running something as close to a normal release as > > possible. > > > > - Charlie > > > > On Sun, Nov 6, 2011 at 7:39 AM, Henri Gomez > wrote: > >> Charles > >> > >> For OpenJDK 8 build/package for OS/X, you told me FASTDEBUG slow down > >> startup stuff. > >> Do you want me to disable it in OSX build/package ? > >> > >> > >> 2011/11/5 Charles Oliver Nutter : > >>> On Sat, Nov 5, 2011 at 5:50 PM, Henri Gomez > wrote: > >>>> Thanks. > >>>> Yes, OpenJDK 7 is using llvm gcc/g++ > >>> > >>> Awesome...now I'm really curious about the potential for OpenJDK on > >>> Native Client via LLVM. > >>> > >>> - Charlie > >>> _______________________________________________ > >>> mlvm-dev mailing list > >>> mlvm-dev at openjdk.java.net > >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >>> > >> _______________________________________________ > >> mlvm-dev mailing list > >> mlvm-dev at openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >> > > _______________________________________________ > > mlvm-dev mailing list > > mlvm-dev at openjdk.java.net > > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111106/52803834/attachment-0001.html From henri.gomez at gmail.com Sun Nov 6 22:54:35 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 7 Nov 2011 07:54:35 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: > Not much. There are a few monitoring/debugging flags that won't work but > they aren't anything a typical user wants to use. The installed package > would be better as a release build. So, I could disable fastdebug in build ? From mroos at roos.com Mon Nov 7 00:51:24 2011 From: mroos at roos.com (Mark Roos) Date: Mon, 7 Nov 2011 00:51:24 -0800 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: >From Henri So, I could disable fastdebug in build ? To charles Do we need the fastdebug to get the asm listing? And is it slower to run or just start up? It seems to run my benchmarks about 30% slower. Since we have Stephen's with fast debug Henri's could be whatever gives the most impressive user experience. I have been bouncing around three as it is anyway. thanks again for the work Henri mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111107/a375d65a/attachment.html From rednaxelafx at gmail.com Mon Nov 7 00:59:04 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 7 Nov 2011 16:59:04 +0800 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: Hi Mark, PrintOptoAssembly (for C2, and PrintLIR for C1) only works in a debug build (which fastdebug is one), where as PrintAssembly works in all builds. If you need more annotated asm listing then you might want PrintOptoAssembly, but if you're just after the code instead of the comments then PrintAssembly should be good enough. fastdebug is indeed slower (by a little; it'll vary depending on the VM args, some args are very expensive), on startup and to run. Regards, Kris Mok On Mon, Nov 7, 2011 at 4:51 PM, Mark Roos wrote: > From Henri > > > So, I could disable fastdebug in build ? > > To charles > Do we need the fastdebug to get the asm listing? And is it slower > to run or just start up? > It seems to run my benchmarks about 30% slower. > > Since we have Stephen's with fast debug Henri's could be whatever gives > the most impressive > user experience. I have been bouncing around three as it is anyway. > > thanks again for the work Henri > mark > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111107/51b6e4bb/attachment.html From henri.gomez at gmail.com Mon Nov 7 01:24:20 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 7 Nov 2011 10:24:20 +0100 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: > From Henri > > So, I could disable fastdebug in build ? > > To charles > ? ? ? ? Do we need the fastdebug to get the asm listing? And is it slower to > run or just start up? > ? ? ? ? It seems to run my benchmarks about 30% slower. > > Since we have Stephen's with fast debug Henri's could be whatever gives the > most impressive > user experience. ?I have been bouncing around three as it is anyway. I could see how to arrange 2 packages, with/without fastdebug. for now build parameters include : DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true I'm wondering if fastbdebug is enabled or not (SKIP_FASTDEBUG_BUILD make me think no but I'm unsure). What would be parameters for DEBUG/NONDEBUG packages ? > thanks again for the work Henri You're welcome From headius at headius.com Mon Nov 7 04:07:33 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 7 Nov 2011 09:07:33 -0300 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: I personally like the PrintAssembly output a lot better...it also annotates line of code, opcode, etc. I don't feel like PrintOptoAssembly is better. - Charlie (mobile) On Nov 7, 2011 3:59 AM, "Krystal Mok" wrote: > Hi Mark, > > PrintOptoAssembly (for C2, and PrintLIR for C1) only works in a debug > build (which fastdebug is one), where as PrintAssembly works in all builds. > If you need more annotated asm listing then you might want > PrintOptoAssembly, but if you're just after the code instead of the > comments then PrintAssembly should be good enough. > > fastdebug is indeed slower (by a little; it'll vary depending on the VM > args, some args are very expensive), on startup and to run. > > Regards, > Kris Mok > > On Mon, Nov 7, 2011 at 4:51 PM, Mark Roos wrote: > >> From Henri >> >> >> So, I could disable fastdebug in build ? >> >> To charles >> Do we need the fastdebug to get the asm listing? And is it slower >> to run or just start up? >> It seems to run my benchmarks about 30% slower. >> >> Since we have Stephen's with fast debug Henri's could be whatever gives >> the most impressive >> user experience. I have been bouncing around three as it is anyway. >> >> thanks again for the work Henri >> mark >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111107/320d25c2/attachment.html From headius at headius.com Mon Nov 7 04:08:48 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 7 Nov 2011 09:08:48 -0300 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: I agree...Stephen's build scripts can continue to give us debug builds, but the value of the OS X package is that our end users can install it easily and test things out. - Charlie (mobile) On Nov 7, 2011 3:52 AM, "Mark Roos" wrote: > From Henri > > So, I could disable fastdebug in build ? > > To charles > Do we need the fastdebug to get the asm listing? And is it slower > to run or just start up? > It seems to run my benchmarks about 30% slower. > > Since we have Stephen's with fast debug Henri's could be whatever gives > the most impressive > user experience. I have been bouncing around three as it is anyway. > > thanks again for the work Henri > mark > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111107/a521afcd/attachment.html From benjamin.john.evans at gmail.com Mon Nov 7 04:14:06 2011 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Mon, 7 Nov 2011 12:14:06 +0000 Subject: OpenJDK 8 on OS/X and XCode 4. In-Reply-To: References: <415631FA-9804-41EF-9C74-47F0E76ADD7A@gmail.com> Message-ID: Exactly. With Adopt-A-JSR and some of the other projects we're pushing, getting a broader community trying out JDK 8 is a great complement. There are a lot of Mac users in our community, and having simple installers is a big help. Thanks, Ben On Nov 7, 2011 12:09 PM, "Charles Oliver Nutter" wrote: > I agree...Stephen's build scripts can continue to give us debug builds, > but the value of the OS X package is that our end users can install it > easily and test things out. > > - Charlie (mobile) > On Nov 7, 2011 3:52 AM, "Mark Roos" wrote: > >> From Henri >> >> So, I could disable fastdebug in build ? >> >> To charles >> Do we need the fastdebug to get the asm listing? And is it slower >> to run or just start up? >> It seems to run my benchmarks about 30% slower. >> >> Since we have Stephen's with fast debug Henri's could be whatever gives >> the most impressive >> user experience. I have been bouncing around three as it is anyway. >> >> thanks again for the work Henri >> mark >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111107/6f236cc6/attachment-0001.html From henri.gomez at gmail.com Tue Nov 8 06:23:40 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 8 Nov 2011 15:23:40 +0100 Subject: mailing list to track Message-ID: Hi to all, I'm tracking hg commit in bsd-port, mac-osxport list to produce OSX packages For DaVinci, I'm now tracking also mlvm-dev but wondering which lists I should track also to produce up to date openjdk8 + mlvm packages for OS/X. Thanks for your advices From john.r.rose at oracle.com Tue Nov 8 12:01:05 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 08 Nov 2011 20:01:05 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: fix corner cases of member resolution Message-ID: <20111108200106.06D1247299@hg.openjdk.java.net> Changeset: b60806559262 Author: jrose Date: 2011-11-08 12:00 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b60806559262 meth-lazy: fix corner cases of member resolution ! meth-lazy.patch From john.r.rose at oracle.com Tue Nov 8 12:01:15 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 08 Nov 2011 20:01:15 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: fix corner cases of member resolution Message-ID: <20111108200116.3CC7C4729A@hg.openjdk.java.net> Changeset: 43493539bcbe Author: jrose Date: 2011-11-08 12:01 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/43493539bcbe meth-lazy: fix corner cases of member resolution ! meth-lazy.patch ! series From henri.gomez at gmail.com Wed Nov 9 00:24:25 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 Nov 2011 09:24:25 +0100 Subject: JAVA_HOME and OSX Message-ID: Hi to all, I just seen a problem with OpenJDK 8 and OSX. java works when providing full path : mbp:workspace henri$ /Library/Java/JavaVirtualMachines/openjdk-1.8-x86_64/Contents/Home/bin/java -version openjdk version "1.8.0-b11-fastdebug" OpenJDK Runtime Environment (build 1.8.0-b11-fastdebug-20111109) OpenJDK 64-Bit Server VM (build 23.0-b03-fastdebug, mixed mode) java fail when setting JAVA_HOME : mbp:workspace henri$ export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-1.8-x86_64/Contents/Home mbp:workspace henri$ java -version Error: could not find libjava.dylib Error: Could not find Java SE Runtime Environment. It was something allready present in openjdk 1.7 from bsd-port and patch is provided. For now, I'll add it to my packaging build process, but it will be fine to get it included in MLVM patches. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: java_md.c.patch Type: application/octet-stream Size: 349 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111109/edb6eb1c/java_md.c.patch From henri.gomez at gmail.com Wed Nov 9 00:35:59 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 Nov 2011 09:35:59 +0100 Subject: disabling fastdebug Message-ID: I'm wondering about make flags to pass to have fastdebug enabled or disabled. for now, I'm using : DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true What should be arguments to have a build with fastdebug enabled or disabled ? Thanks to all From headius at headius.com Wed Nov 9 02:37:46 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 9 Nov 2011 10:37:46 +0000 Subject: disabling fastdebug In-Reply-To: References: Message-ID: On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: > I'm wondering about make flags to pass to have fastdebug enabled or disabled. > > for now, I'm using : > > DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a release build. It's a very confusing name. - Charlie From henri.gomez at gmail.com Wed Nov 9 02:39:49 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 Nov 2011 11:39:49 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: 2011/11/9 Charles Oliver Nutter : > On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: >> I'm wondering about make flags to pass to have fastdebug enabled or disabled. >> >> for now, I'm using : >> >> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true > > I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a > release build. It's a very confusing name. Yes. I'll try it right now From henri.gomez at gmail.com Wed Nov 9 06:15:29 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 9 Nov 2011 15:15:29 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: 2011/11/9 Henri Gomez : > 2011/11/9 Charles Oliver Nutter : >> On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: >>> I'm wondering about make flags to pass to have fastdebug enabled or disabled. >>> >>> for now, I'm using : >>> >>> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true >> >> I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a >> release build. It's a very confusing name. > > Yes. > > I'll try it right now It's unclear. settings SKIP_FASTDEBUG_BUILD to false produce a j2sdk-image under sources/build/bsd-amd64-fastdebug instead of sources/build/bsd-amd64 And even if I set DEBUG_NAME to release instead of fastdebug. I'm puzzled and need some clarifications :) From john.r.rose at oracle.com Wed Nov 9 16:35:52 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 10 Nov 2011 00:35:52 +0000 Subject: hg: mlvm/mlvm/jdk: 7030453: incorporate more reviewer comments Message-ID: <20111110003553.6EFCB472C3@hg.openjdk.java.net> Changeset: 8d64af6bcdfe Author: jrose Date: 2011-11-09 16:35 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8d64af6bcdfe 7030453: incorporate more reviewer comments ! cval-tune-7030453.patch From john.r.rose at oracle.com Wed Nov 9 18:41:55 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 10 Nov 2011 02:41:55 +0000 Subject: hg: mlvm/mlvm/jdk: indy.pack: implement constant pool groups, for JDK 7 constants Message-ID: <20111110024155.7A606472C4@hg.openjdk.java.net> Changeset: 7349c4e6fef7 Author: jrose Date: 2011-11-09 18:41 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7349c4e6fef7 indy.pack: implement constant pool groups, for JDK 7 constants ! indy.pack.patch From headius at headius.com Thu Nov 10 05:28:00 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 10 Nov 2011 14:28:00 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: Ok, I think I figured out the problem. Stephen's build includes DEBUG_NAME and SKIP_FASTDEBUG_BUILD in the default set of variables, around line 199 in update.sh. The problem seems to be that if DEBUG_NAME is set to "fastdebug" that's the target used to build the JDK. Setting the other flags doesn't seem to have any effect then. I removed that line and set SKIP_FASTDEBUG_BUILD and SKIP_DEBUG_BUILD both to "true", and it has built a "product" build now instead. FWIW, I also cranked HOTSPOT_BUILD_JOBS up to 8 for my 4-core i7 (8 with hyperthreading) and the build goes much faster. system ~/projects/mlvm/sources $ build/bsd-amd64/j2sdk-image/bin/java -version openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-headius_2011_11_10_14_11-b00) OpenJDK 64-Bit Server VM (build 23.0-b03, mixed mode) The product build is definitely faster at starting up and running JRuby benchmarks (first with Henri's fastdebug .dmg, then with my product build): system ~/projects/jruby $ time jruby -v jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit Server VM 1.8.0-b11-fastdebug) [darwin-amd64-java] real 0m1.999s user 0m2.106s sys 0m0.083s system ~/projects/jruby $ jruby bench/bench_fib_complex.rb normal fib 28.0 (?7.1%) i/s - 136 in 4.883273s (cycle=2) fib with variables 28.2 (?0.0%) i/s - 142 in 5.033941s (cycle=2) fib with constants 21.2 (?4.7%) i/s - 106 in 5.006481s (cycle=1) fib with additional calls 21.3 (?0.0%) i/s - 107 in 5.030669s (cycle=1) fib with constants and additional calls 19.0 (?10.5%) i/s - 94 in 5.007942s (cycle=1) system ~/projects/jruby $ export JAVA_HOME=/Users/headius/projects/mlvm/sources/build/bsd-amd64/j2sdk-image system ~/projects/jruby $ time jruby -v jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit Server VM 1.8.0-internal) [darwin-amd64-java] real 0m0.514s user 0m0.518s sys 0m0.049s system ~/projects/jruby $ jruby bench/bench_fib_complex.rb normal fib 31.4 (?3.2%) i/s - 159 in 5.062433s (cycle=3) fib with variables 30.0 (?3.3%) i/s - 150 in 4.999186s (cycle=3) fib with constants 23.3 (?0.0%) i/s - 118 in 5.069851s (cycle=2) fib with additional calls 23.7 (?0.0%) i/s - 120 in 5.059472s (cycle=2) fib with constants and additional calls 21.5 (?0.0%) i/s - 108 in 5.029512s (cycle=2) - Charlie On Wed, Nov 9, 2011 at 3:15 PM, Henri Gomez wrote: > 2011/11/9 Henri Gomez : >> 2011/11/9 Charles Oliver Nutter : >>> On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: >>>> I'm wondering about make flags to pass to have fastdebug enabled or disabled. >>>> >>>> for now, I'm using : >>>> >>>> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true >>> >>> I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a >>> release build. It's a very confusing name. >> >> Yes. >> >> I'll try it right now > > It's unclear. > > settings SKIP_FASTDEBUG_BUILD to false produce a j2sdk-image under > sources/build/bsd-amd64-fastdebug instead of sources/build/bsd-amd64 > And even if I set DEBUG_NAME to release instead of fastdebug. > > I'm puzzled and need some clarifications :) > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From henri.gomez at gmail.com Thu Nov 10 06:07:10 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 15:07:10 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: And you didn't set DEBUG_NAME ? Le 10 nov. 2011 ? 14:28, Charles Oliver Nutter a ?crit : > Ok, I think I figured out the problem. > > Stephen's build includes DEBUG_NAME and SKIP_FASTDEBUG_BUILD in the > default set of variables, around line 199 in update.sh. The problem > seems to be that if DEBUG_NAME is set to "fastdebug" that's the target > used to build the JDK. Setting the other flags doesn't seem to have > any effect then. > > I removed that line and set SKIP_FASTDEBUG_BUILD and SKIP_DEBUG_BUILD > both to "true", and it has built a "product" build now instead. > > FWIW, I also cranked HOTSPOT_BUILD_JOBS up to 8 for my 4-core i7 (8 > with hyperthreading) and the build goes much faster. > > system ~/projects/mlvm/sources $ build/bsd-amd64/j2sdk-image/bin/java -version > openjdk version "1.8.0-internal" > OpenJDK Runtime Environment (build 1.8.0-internal-headius_2011_11_10_14_11-b00) > OpenJDK 64-Bit Server VM (build 23.0-b03, mixed mode) > > The product build is > definitely faster at starting up and running JRuby benchmarks (first > with Henri's fastdebug .dmg, then with my product build): > > system ~/projects/jruby $ time jruby -v > jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit > Server VM 1.8.0-b11-fastdebug) [darwin-amd64-java] > > real 0m1.999s > user 0m2.106s > sys 0m0.083s > > system ~/projects/jruby $ jruby bench/bench_fib_complex.rb > normal fib 28.0 (?7.1%) i/s - 136 in > 4.883273s (cycle=2) > fib with variables 28.2 (?0.0%) i/s - 142 in > 5.033941s (cycle=2) > fib with constants 21.2 (?4.7%) i/s - 106 in > 5.006481s (cycle=1) > fib with additional calls > 21.3 (?0.0%) i/s - 107 in > 5.030669s (cycle=1) > fib with constants and additional calls > 19.0 (?10.5%) i/s - 94 in > 5.007942s (cycle=1) > > system ~/projects/jruby $ export > JAVA_HOME=/Users/headius/projects/mlvm/sources/build/bsd-amd64/j2sdk-image > > system ~/projects/jruby $ time jruby -v > jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit > Server VM 1.8.0-internal) [darwin-amd64-java] > > real 0m0.514s > user 0m0.518s > sys 0m0.049s > > system ~/projects/jruby $ jruby bench/bench_fib_complex.rb > normal fib 31.4 (?3.2%) i/s - 159 in > 5.062433s (cycle=3) > fib with variables 30.0 (?3.3%) i/s - 150 in > 4.999186s (cycle=3) > fib with constants 23.3 (?0.0%) i/s - 118 in > 5.069851s (cycle=2) > fib with additional calls > 23.7 (?0.0%) i/s - 120 in > 5.059472s (cycle=2) > fib with constants and additional calls > 21.5 (?0.0%) i/s - 108 in > 5.029512s (cycle=2) > > - Charlie > > On Wed, Nov 9, 2011 at 3:15 PM, Henri Gomez wrote: >> 2011/11/9 Henri Gomez : >>> 2011/11/9 Charles Oliver Nutter : >>>> On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: >>>>> I'm wondering about make flags to pass to have fastdebug enabled or disabled. >>>>> >>>>> for now, I'm using : >>>>> >>>>> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true >>>> >>>> I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a >>>> release build. It's a very confusing name. >>> >>> Yes. >>> >>> I'll try it right now >> >> It's unclear. >> >> settings SKIP_FASTDEBUG_BUILD to false produce a j2sdk-image under >> sources/build/bsd-amd64-fastdebug instead of sources/build/bsd-amd64 >> And even if I set DEBUG_NAME to release instead of fastdebug. >> >> I'm puzzled and need some clarifications :) >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From henri.gomez at gmail.com Thu Nov 10 06:37:52 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 15:37:52 +0100 Subject: JAVA_HOME and OSX In-Reply-To: References: Message-ID: Could someone include this patch in patchsets ? 2011/11/9 Henri Gomez : > Hi to all, > > I just seen a problem with OpenJDK 8 and OSX. > > java works when providing full path : > > mbp:workspace henri$ > /Library/Java/JavaVirtualMachines/openjdk-1.8-x86_64/Contents/Home/bin/java > -version > openjdk version "1.8.0-b11-fastdebug" > OpenJDK Runtime Environment (build 1.8.0-b11-fastdebug-20111109) > OpenJDK 64-Bit Server VM (build 23.0-b03-fastdebug, mixed mode) > > java fail when setting JAVA_HOME : > > mbp:workspace henri$ export > JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-1.8-x86_64/Contents/Home > mbp:workspace henri$ java -version > Error: could not find libjava.dylib > Error: Could not find Java SE Runtime Environment. > > It was something allready present in openjdk 1.7 from bsd-port and > patch is provided. > For now, I'll add it to my packaging build process, but it will be > fine to get it included in MLVM patches. > > Cheers > From headius at headius.com Thu Nov 10 07:09:44 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 10 Nov 2011 16:09:44 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: I removed DEBUG_NAME completely...so it was not set to anything. On Thu, Nov 10, 2011 at 3:07 PM, Henri Gomez wrote: > And you didn't set DEBUG_NAME ? > > Le 10 nov. 2011 ? 14:28, Charles Oliver Nutter a ?crit : > >> Ok, I think I figured out the problem. >> >> Stephen's build includes DEBUG_NAME and SKIP_FASTDEBUG_BUILD in the >> default set of variables, around line 199 in update.sh. The problem >> seems to be that if DEBUG_NAME is set to "fastdebug" that's the target >> used to build the JDK. Setting the other flags doesn't seem to have >> any effect then. >> >> I removed that line and set SKIP_FASTDEBUG_BUILD and SKIP_DEBUG_BUILD >> both to "true", and it has built a "product" build now instead. >> >> FWIW, I also cranked HOTSPOT_BUILD_JOBS up to 8 for my 4-core i7 (8 >> with hyperthreading) and the build goes much faster. >> >> system ~/projects/mlvm/sources $ build/bsd-amd64/j2sdk-image/bin/java -version >> openjdk version "1.8.0-internal" >> OpenJDK Runtime Environment (build 1.8.0-internal-headius_2011_11_10_14_11-b00) >> OpenJDK 64-Bit Server VM (build 23.0-b03, mixed mode) >> >> The product build is >> definitely faster at starting up and running JRuby benchmarks (first >> with Henri's fastdebug .dmg, then with my product build): >> >> system ~/projects/jruby $ time jruby -v >> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit >> Server VM 1.8.0-b11-fastdebug) [darwin-amd64-java] >> >> real ? ?0m1.999s >> user ? ?0m2.106s >> sys ? ?0m0.083s >> >> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb >> ? ? ? ? ?normal fib ? ? ? 28.0 (?7.1%) i/s - ? ? ? ?136 in >> 4.883273s (cycle=2) >> ?fib with variables ? ? ? 28.2 (?0.0%) i/s - ? ? ? ?142 in >> 5.033941s (cycle=2) >> ?fib with constants ? ? ? 21.2 (?4.7%) i/s - ? ? ? ?106 in >> 5.006481s (cycle=1) >> fib with additional calls >> ? ? ? ? ? ? ? ? ? ? ? ? ? 21.3 (?0.0%) i/s - ? ? ? ?107 in >> 5.030669s (cycle=1) >> fib with constants and additional calls >> ? ? ? ? ? ? ? ? ? ? ? ? ? 19.0 (?10.5%) i/s - ? ? ? ? 94 in >> 5.007942s (cycle=1) >> >> system ~/projects/jruby $ export >> JAVA_HOME=/Users/headius/projects/mlvm/sources/build/bsd-amd64/j2sdk-image >> >> system ~/projects/jruby $ time jruby -v >> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit >> Server VM 1.8.0-internal) [darwin-amd64-java] >> >> real ? ?0m0.514s >> user ? ?0m0.518s >> sys ? ?0m0.049s >> >> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb >> ? ? ? ? ?normal fib ? ? ? 31.4 (?3.2%) i/s - ? ? ? ?159 in >> 5.062433s (cycle=3) >> ?fib with variables ? ? ? 30.0 (?3.3%) i/s - ? ? ? ?150 in >> 4.999186s (cycle=3) >> ?fib with constants ? ? ? 23.3 (?0.0%) i/s - ? ? ? ?118 in >> 5.069851s (cycle=2) >> fib with additional calls >> ? ? ? ? ? ? ? ? ? ? ? ? ? 23.7 (?0.0%) i/s - ? ? ? ?120 in >> 5.059472s (cycle=2) >> fib with constants and additional calls >> ? ? ? ? ? ? ? ? ? ? ? ? ? 21.5 (?0.0%) i/s - ? ? ? ?108 in >> 5.029512s (cycle=2) >> >> - Charlie >> >> On Wed, Nov 9, 2011 at 3:15 PM, Henri Gomez wrote: >>> 2011/11/9 Henri Gomez : >>>> 2011/11/9 Charles Oliver Nutter : >>>>> On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: >>>>>> I'm wondering about make flags to pass to have fastdebug enabled or disabled. >>>>>> >>>>>> for now, I'm using : >>>>>> >>>>>> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true >>>>> >>>>> I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a >>>>> release build. It's a very confusing name. >>>> >>>> Yes. >>>> >>>> I'll try it right now >>> >>> It's unclear. >>> >>> settings SKIP_FASTDEBUG_BUILD to false produce a j2sdk-image under >>> sources/build/bsd-amd64-fastdebug instead of sources/build/bsd-amd64 >>> And even if I set DEBUG_NAME to release instead of fastdebug. >>> >>> I'm puzzled and need some clarifications :) >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From henri.gomez at gmail.com Thu Nov 10 07:15:32 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 16:15:32 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: Done the same. We'll see about build results. If it works, I'll be able to produce packages with/without fastdebug. Le 10 nov. 2011 ? 16:09, Charles Oliver Nutter a ?crit : > I removed DEBUG_NAME completely...so it was not set to anything. > > On Thu, Nov 10, 2011 at 3:07 PM, Henri Gomez wrote: >> And you didn't set DEBUG_NAME ? >> >> Le 10 nov. 2011 ? 14:28, Charles Oliver Nutter a ?crit : >> >>> Ok, I think I figured out the problem. >>> >>> Stephen's build includes DEBUG_NAME and SKIP_FASTDEBUG_BUILD in the >>> default set of variables, around line 199 in update.sh. The problem >>> seems to be that if DEBUG_NAME is set to "fastdebug" that's the target >>> used to build the JDK. Setting the other flags doesn't seem to have >>> any effect then. >>> >>> I removed that line and set SKIP_FASTDEBUG_BUILD and SKIP_DEBUG_BUILD >>> both to "true", and it has built a "product" build now instead. >>> >>> FWIW, I also cranked HOTSPOT_BUILD_JOBS up to 8 for my 4-core i7 (8 >>> with hyperthreading) and the build goes much faster. >>> >>> system ~/projects/mlvm/sources $ build/bsd-amd64/j2sdk-image/bin/java -version >>> openjdk version "1.8.0-internal" >>> OpenJDK Runtime Environment (build 1.8.0-internal-headius_2011_11_10_14_11-b00) >>> OpenJDK 64-Bit Server VM (build 23.0-b03, mixed mode) >>> >>> The product build is >>> definitely faster at starting up and running JRuby benchmarks (first >>> with Henri's fastdebug .dmg, then with my product build): >>> >>> system ~/projects/jruby $ time jruby -v >>> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit >>> Server VM 1.8.0-b11-fastdebug) [darwin-amd64-java] >>> >>> real 0m1.999s >>> user 0m2.106s >>> sys 0m0.083s >>> >>> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb >>> normal fib 28.0 (?7.1%) i/s - 136 in >>> 4.883273s (cycle=2) >>> fib with variables 28.2 (?0.0%) i/s - 142 in >>> 5.033941s (cycle=2) >>> fib with constants 21.2 (?4.7%) i/s - 106 in >>> 5.006481s (cycle=1) >>> fib with additional calls >>> 21.3 (?0.0%) i/s - 107 in >>> 5.030669s (cycle=1) >>> fib with constants and additional calls >>> 19.0 (?10.5%) i/s - 94 in >>> 5.007942s (cycle=1) >>> >>> system ~/projects/jruby $ export >>> JAVA_HOME=/Users/headius/projects/mlvm/sources/build/bsd-amd64/j2sdk-image >>> >>> system ~/projects/jruby $ time jruby -v >>> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit >>> Server VM 1.8.0-internal) [darwin-amd64-java] >>> >>> real 0m0.514s >>> user 0m0.518s >>> sys 0m0.049s >>> >>> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb >>> normal fib 31.4 (?3.2%) i/s - 159 in >>> 5.062433s (cycle=3) >>> fib with variables 30.0 (?3.3%) i/s - 150 in >>> 4.999186s (cycle=3) >>> fib with constants 23.3 (?0.0%) i/s - 118 in >>> 5.069851s (cycle=2) >>> fib with additional calls >>> 23.7 (?0.0%) i/s - 120 in >>> 5.059472s (cycle=2) >>> fib with constants and additional calls >>> 21.5 (?0.0%) i/s - 108 in >>> 5.029512s (cycle=2) >>> >>> - Charlie >>> >>> On Wed, Nov 9, 2011 at 3:15 PM, Henri Gomez wrote: >>>> 2011/11/9 Henri Gomez : >>>>> 2011/11/9 Charles Oliver Nutter : >>>>>> On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: >>>>>>> I'm wondering about make flags to pass to have fastdebug enabled or disabled. >>>>>>> >>>>>>> for now, I'm using : >>>>>>> >>>>>>> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true >>>>>> >>>>>> I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a >>>>>> release build. It's a very confusing name. >>>>> >>>>> Yes. >>>>> >>>>> I'll try it right now >>>> >>>> It's unclear. >>>> >>>> settings SKIP_FASTDEBUG_BUILD to false produce a j2sdk-image under >>>> sources/build/bsd-amd64-fastdebug instead of sources/build/bsd-amd64 >>>> And even if I set DEBUG_NAME to release instead of fastdebug. >>>> >>>> I'm puzzled and need some clarifications :) >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From henri.gomez at gmail.com Thu Nov 10 10:13:31 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 19:13:31 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: I produced a DMG in release mode (built without fastdebug). It's available here : http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-20111110-release.dmg Cheers 2011/11/10 Henri Gomez : > Done the same. > > We'll see about build results. > > If it works, I'll be able to produce packages with/without fastdebug. > > Le 10 nov. 2011 ? 16:09, Charles Oliver Nutter a ?crit : > >> I removed DEBUG_NAME completely...so it was not set to anything. >> >> On Thu, Nov 10, 2011 at 3:07 PM, Henri Gomez wrote: >>> And you didn't set DEBUG_NAME ? >>> >>> Le 10 nov. 2011 ? 14:28, Charles Oliver Nutter a ?crit : >>> >>>> Ok, I think I figured out the problem. >>>> >>>> Stephen's build includes DEBUG_NAME and SKIP_FASTDEBUG_BUILD in the >>>> default set of variables, around line 199 in update.sh. The problem >>>> seems to be that if DEBUG_NAME is set to "fastdebug" that's the target >>>> used to build the JDK. Setting the other flags doesn't seem to have >>>> any effect then. >>>> >>>> I removed that line and set SKIP_FASTDEBUG_BUILD and SKIP_DEBUG_BUILD >>>> both to "true", and it has built a "product" build now instead. >>>> >>>> FWIW, I also cranked HOTSPOT_BUILD_JOBS up to 8 for my 4-core i7 (8 >>>> with hyperthreading) and the build goes much faster. >>>> >>>> system ~/projects/mlvm/sources $ build/bsd-amd64/j2sdk-image/bin/java -version >>>> openjdk version "1.8.0-internal" >>>> OpenJDK Runtime Environment (build 1.8.0-internal-headius_2011_11_10_14_11-b00) >>>> OpenJDK 64-Bit Server VM (build 23.0-b03, mixed mode) >>>> >>>> The product build is >>>> definitely faster at starting up and running JRuby benchmarks (first >>>> with Henri's fastdebug .dmg, then with my product build): >>>> >>>> system ~/projects/jruby $ time jruby -v >>>> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit >>>> Server VM 1.8.0-b11-fastdebug) [darwin-amd64-java] >>>> >>>> real ? ?0m1.999s >>>> user ? ?0m2.106s >>>> sys ? ?0m0.083s >>>> >>>> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb >>>> ? ? ? ? ?normal fib ? ? ? 28.0 (?7.1%) i/s - ? ? ? ?136 in >>>> 4.883273s (cycle=2) >>>> ?fib with variables ? ? ? 28.2 (?0.0%) i/s - ? ? ? ?142 in >>>> 5.033941s (cycle=2) >>>> ?fib with constants ? ? ? 21.2 (?4.7%) i/s - ? ? ? ?106 in >>>> 5.006481s (cycle=1) >>>> fib with additional calls >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? 21.3 (?0.0%) i/s - ? ? ? ?107 in >>>> 5.030669s (cycle=1) >>>> fib with constants and additional calls >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? 19.0 (?10.5%) i/s - ? ? ? ? 94 in >>>> 5.007942s (cycle=1) >>>> >>>> system ~/projects/jruby $ export >>>> JAVA_HOME=/Users/headius/projects/mlvm/sources/build/bsd-amd64/j2sdk-image >>>> >>>> system ~/projects/jruby $ time jruby -v >>>> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit >>>> Server VM 1.8.0-internal) [darwin-amd64-java] >>>> >>>> real ? ?0m0.514s >>>> user ? ?0m0.518s >>>> sys ? ?0m0.049s >>>> >>>> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb >>>> ? ? ? ? ?normal fib ? ? ? 31.4 (?3.2%) i/s - ? ? ? ?159 in >>>> 5.062433s (cycle=3) >>>> ?fib with variables ? ? ? 30.0 (?3.3%) i/s - ? ? ? ?150 in >>>> 4.999186s (cycle=3) >>>> ?fib with constants ? ? ? 23.3 (?0.0%) i/s - ? ? ? ?118 in >>>> 5.069851s (cycle=2) >>>> fib with additional calls >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? 23.7 (?0.0%) i/s - ? ? ? ?120 in >>>> 5.059472s (cycle=2) >>>> fib with constants and additional calls >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? 21.5 (?0.0%) i/s - ? ? ? ?108 in >>>> 5.029512s (cycle=2) >>>> >>>> - Charlie >>>> >>>> On Wed, Nov 9, 2011 at 3:15 PM, Henri Gomez wrote: >>>>> 2011/11/9 Henri Gomez : >>>>>> 2011/11/9 Charles Oliver Nutter : >>>>>>> On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez wrote: >>>>>>>> I'm wondering about make flags to pass to have fastdebug enabled or disabled. >>>>>>>> >>>>>>>> for now, I'm using : >>>>>>>> >>>>>>>> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true >>>>>>> >>>>>>> I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a >>>>>>> release build. It's a very confusing name. >>>>>> >>>>>> Yes. >>>>>> >>>>>> I'll try it right now >>>>> >>>>> It's unclear. >>>>> >>>>> settings SKIP_FASTDEBUG_BUILD to false produce a j2sdk-image under >>>>> sources/build/bsd-amd64-fastdebug instead of sources/build/bsd-amd64 >>>>> And even if I set DEBUG_NAME to release instead of fastdebug. >>>>> >>>>> I'm puzzled and need some clarifications :) >>>>> _______________________________________________ >>>>> mlvm-dev mailing list >>>>> mlvm-dev at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From stephen.bannasch at deanbrook.org Thu Nov 10 11:44:10 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Thu, 10 Nov 2011 14:44:10 -0500 Subject: disabling fastdebug In-Reply-To: References: Message-ID: At 2:28 PM +0100 11/10/11, Charles Oliver Nutter wrote: >Ok, I think I figured out the problem. > >Stephen's build includes DEBUG_NAME and SKIP_FASTDEBUG_BUILD in the >default set of variables, around line 199 in update.sh. The problem >seems to be that if DEBUG_NAME is set to "fastdebug" that's the target >used to build the JDK. Setting the other flags doesn't seem to have >any effect then. > >I removed that line and set SKIP_FASTDEBUG_BUILD and SKIP_DEBUG_BUILD >both to "true", and it has built a "product" build now instead. > >FWIW, I also cranked HOTSPOT_BUILD_JOBS up to 8 for my 4-core i7 (8 >with hyperthreading) and the build goes much faster. Thanks for figuring that out. I updated my build scripts so a regular production build is created: https://gist.github.com/gists/243072 I put the following in as comments around line 200: # include the following to enable a FASTDEBUG build: # DEBUG_NAME=fastdebug # and remove the following: # SKIP_FASTDEBUG_BUILD=true # SKIP_DEBUG_BUILD=true On my Mac OS X 10.6.8 system with a 2.66 GHz Intel Core i7, 8GM 1067 MHz DDR3 I get the following times for building mlvm and running the java/lang/invoke tests and the java/dyn/CoroutineTest test: HOTSPOT_BUILD_JOBS=2 22m HOTSPOT_BUILD_JOBS=4 19m HOTSPOT_BUILD_JOBS=8 20m From henri.gomez at gmail.com Thu Nov 10 11:52:10 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 10 Nov 2011 20:52:10 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: > I updated my build scripts so a regular production build is created: > > ?https://gist.github.com/gists/243072 > > I put the following in as comments around line 200: > > ?# include the following to enable a FASTDEBUG build: > ?# ? ?DEBUG_NAME=fastdebug > ?# and remove the following: > ?# ? SKIP_FASTDEBUG_BUILD=true > ?# ? SKIP_DEBUG_BUILD=true > > On my Mac OS X 10.6.8 system with a 2.66 GHz Intel Core i7, 8GM 1067 MHz DDR3 I get the following times for building mlvm and running the java/lang/invoke tests and the java/dyn/CoroutineTest test: > > ?HOTSPOT_BUILD_JOBS=2 ? 22m > ?HOTSPOT_BUILD_JOBS=4 ? 19m > ?HOTSPOT_BUILD_JOBS=8 ? 20m Nice. I updated my Jenkins build job and a simple check box make me produce fastdebug or release package, so we could get both available at http://code.google.com/p/openjdk-osx-build/ From john.r.rose at oracle.com Fri Nov 11 23:44:46 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 12 Nov 2011 07:44:46 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: update Message-ID: <20111112074446.E4B934734F@hg.openjdk.java.net> Changeset: 8e868df6045e Author: jrose Date: 2011-11-11 23:44 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8e868df6045e meth-lazy: update ! meth-lazy.patch From headius at headius.com Sat Nov 12 11:09:04 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 12 Nov 2011 20:09:04 +0100 Subject: disabling fastdebug In-Reply-To: References: Message-ID: Thanks, Henri! Works great! - Charlie (mobile) On Nov 10, 2011 7:13 PM, "Henri Gomez" wrote: > I produced a DMG in release mode (built without fastdebug). > > It's available here : > > > http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-20111110-release.dmg > > Cheers > > 2011/11/10 Henri Gomez : > > Done the same. > > > > We'll see about build results. > > > > If it works, I'll be able to produce packages with/without fastdebug. > > > > Le 10 nov. 2011 ? 16:09, Charles Oliver Nutter a > ?crit : > > > >> I removed DEBUG_NAME completely...so it was not set to anything. > >> > >> On Thu, Nov 10, 2011 at 3:07 PM, Henri Gomez > wrote: > >>> And you didn't set DEBUG_NAME ? > >>> > >>> Le 10 nov. 2011 ? 14:28, Charles Oliver Nutter > a ?crit : > >>> > >>>> Ok, I think I figured out the problem. > >>>> > >>>> Stephen's build includes DEBUG_NAME and SKIP_FASTDEBUG_BUILD in the > >>>> default set of variables, around line 199 in update.sh. The problem > >>>> seems to be that if DEBUG_NAME is set to "fastdebug" that's the target > >>>> used to build the JDK. Setting the other flags doesn't seem to have > >>>> any effect then. > >>>> > >>>> I removed that line and set SKIP_FASTDEBUG_BUILD and SKIP_DEBUG_BUILD > >>>> both to "true", and it has built a "product" build now instead. > >>>> > >>>> FWIW, I also cranked HOTSPOT_BUILD_JOBS up to 8 for my 4-core i7 (8 > >>>> with hyperthreading) and the build goes much faster. > >>>> > >>>> system ~/projects/mlvm/sources $ build/bsd-amd64/j2sdk-image/bin/java > -version > >>>> openjdk version "1.8.0-internal" > >>>> OpenJDK Runtime Environment (build > 1.8.0-internal-headius_2011_11_10_14_11-b00) > >>>> OpenJDK 64-Bit Server VM (build 23.0-b03, mixed mode) > >>>> > >>>> The product build is > >>>> definitely faster at starting up and running JRuby benchmarks (first > >>>> with Henri's fastdebug .dmg, then with my product build): > >>>> > >>>> system ~/projects/jruby $ time jruby -v > >>>> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit > >>>> Server VM 1.8.0-b11-fastdebug) [darwin-amd64-java] > >>>> > >>>> real 0m1.999s > >>>> user 0m2.106s > >>>> sys 0m0.083s > >>>> > >>>> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb > >>>> normal fib 28.0 (?7.1%) i/s - 136 in > >>>> 4.883273s (cycle=2) > >>>> fib with variables 28.2 (?0.0%) i/s - 142 in > >>>> 5.033941s (cycle=2) > >>>> fib with constants 21.2 (?4.7%) i/s - 106 in > >>>> 5.006481s (cycle=1) > >>>> fib with additional calls > >>>> 21.3 (?0.0%) i/s - 107 in > >>>> 5.030669s (cycle=1) > >>>> fib with constants and additional calls > >>>> 19.0 (?10.5%) i/s - 94 in > >>>> 5.007942s (cycle=1) > >>>> > >>>> system ~/projects/jruby $ export > >>>> > JAVA_HOME=/Users/headius/projects/mlvm/sources/build/bsd-amd64/j2sdk-image > >>>> > >>>> system ~/projects/jruby $ time jruby -v > >>>> jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-07 8e852ac) (OpenJDK 64-Bit > >>>> Server VM 1.8.0-internal) [darwin-amd64-java] > >>>> > >>>> real 0m0.514s > >>>> user 0m0.518s > >>>> sys 0m0.049s > >>>> > >>>> system ~/projects/jruby $ jruby bench/bench_fib_complex.rb > >>>> normal fib 31.4 (?3.2%) i/s - 159 in > >>>> 5.062433s (cycle=3) > >>>> fib with variables 30.0 (?3.3%) i/s - 150 in > >>>> 4.999186s (cycle=3) > >>>> fib with constants 23.3 (?0.0%) i/s - 118 in > >>>> 5.069851s (cycle=2) > >>>> fib with additional calls > >>>> 23.7 (?0.0%) i/s - 120 in > >>>> 5.059472s (cycle=2) > >>>> fib with constants and additional calls > >>>> 21.5 (?0.0%) i/s - 108 in > >>>> 5.029512s (cycle=2) > >>>> > >>>> - Charlie > >>>> > >>>> On Wed, Nov 9, 2011 at 3:15 PM, Henri Gomez > wrote: > >>>>> 2011/11/9 Henri Gomez : > >>>>>> 2011/11/9 Charles Oliver Nutter : > >>>>>>> On Wed, Nov 9, 2011 at 8:35 AM, Henri Gomez > wrote: > >>>>>>>> I'm wondering about make flags to pass to have fastdebug enabled > or disabled. > >>>>>>>> > >>>>>>>> for now, I'm using : > >>>>>>>> > >>>>>>>> DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true > >>>>>>> > >>>>>>> I believe you just need to set SKIP_FASTDEBUG_BUILD=false to get a > >>>>>>> release build. It's a very confusing name. > >>>>>> > >>>>>> Yes. > >>>>>> > >>>>>> I'll try it right now > >>>>> > >>>>> It's unclear. > >>>>> > >>>>> settings SKIP_FASTDEBUG_BUILD to false produce a j2sdk-image under > >>>>> sources/build/bsd-amd64-fastdebug instead of sources/build/bsd-amd64 > >>>>> And even if I set DEBUG_NAME to release instead of fastdebug. > >>>>> > >>>>> I'm puzzled and need some clarifications :) > >>>>> _______________________________________________ > >>>>> mlvm-dev mailing list > >>>>> mlvm-dev at openjdk.java.net > >>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >>>>> > >>>> _______________________________________________ > >>>> mlvm-dev mailing list > >>>> mlvm-dev at openjdk.java.net > >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >>> _______________________________________________ > >>> mlvm-dev mailing list > >>> mlvm-dev at openjdk.java.net > >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >>> > >> _______________________________________________ > >> mlvm-dev mailing list > >> mlvm-dev at openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111112/ae6f1db5/attachment.html From behrangsa at gmail.com Thu Nov 17 04:31:52 2011 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Thu, 17 Nov 2011 23:31:52 +1100 Subject: OpenJDK 8 + lambdas build for OS X Message-ID: Hi all, I just grabbed the latest version of the OpenJDK 8 build from http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-20111112-release.dmg but it doesn't seem to contain the recent drop of lambdas, as I was unable to compile this simple Java class: public class Main { public static void main(String[] args) { runMe(() -> {}); } public static void runMe(Runnable r) { r.run(); } } Or am I using an incorrect syntax? Or is it that the lambdas aren't still included in the builds provided by that Google Code project? Cheers, Behrang Saeedzadeh http://www.behrang.org From benjamin.john.evans at gmail.com Thu Nov 17 05:02:42 2011 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 17 Nov 2011 14:02:42 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: Message-ID: Hi, My understanding is that lambdas are currently a separate hg forest (to allow the lambdas team to go faster), and that the team will be bringing code across from lambdas into jdk8 mainline, and then rebaselining. So it may not be possible to build a combined jdk8 + lambdas at the moment. (Brian, please correct me if I'm wrong). Henri - what's the situation with your builds? Would it be a lot of work to also build the lambdas forest for OS X? I think it would be very useful to tide us over until the rebaselining has all occurred. Thanks, Ben On Thu, Nov 17, 2011 at 1:31 PM, Behrang Saeedzadeh wrote: > Hi all, > > I just grabbed the latest version of the OpenJDK 8 build from > http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-20111112-release.dmg > but it doesn't seem to contain the recent drop of lambdas, as I was > unable to compile this simple Java class: > > public class Main { > > ? ? ? ?public static void main(String[] args) { > ? ? ? ? ? ? ? ?runMe(() -> {}); > ? ? ? ?} > > ? ? ? ?public static void runMe(Runnable r) { > ? ? ? ? ? ? ? ?r.run(); > ? ? ? ?} > > } > > Or am I using an incorrect syntax? Or is it that the lambdas aren't > still included in the builds provided by that Google Code project? > > Cheers, > Behrang Saeedzadeh > http://www.behrang.org > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From forax at univ-mlv.fr Thu Nov 17 05:33:01 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 17 Nov 2011 14:33:01 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: Message-ID: <4EC50D0D.3090305@univ-mlv.fr> Hi Behrang, the lambda workspace is not yet included in the master workspace of openjdk 8 because a lot of APIs/implementations are too young/too experimental. R?mi On 11/17/2011 01:31 PM, Behrang Saeedzadeh wrote: > Hi all, > > I just grabbed the latest version of the OpenJDK 8 build from > http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-20111112-release.dmg > but it doesn't seem to contain the recent drop of lambdas, as I was > unable to compile this simple Java class: > > public class Main { > > public static void main(String[] args) { > runMe(() -> {}); > } > > public static void runMe(Runnable r) { > r.run(); > } > > } > > Or am I using an incorrect syntax? Or is it that the lambdas aren't > still included in the builds provided by that Google Code project? > > Cheers, > Behrang Saeedzadeh > http://www.behrang.org > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From dalibor.topic at oracle.com Thu Nov 17 05:46:42 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 17 Nov 2011 14:46:42 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: Message-ID: <4EC51042.7010800@oracle.com> On 11/17/11 2:02 PM, Ben Evans wrote: > Hi, > > My understanding is that lambdas are currently a separate hg forest > (to allow the lambdas team to go faster), and that the team will be > bringing code across from lambdas into jdk8 mainline, and then > rebaselining. Yeah, in general in OpenJDK we tend to create new Projects for new major features (like a mac port, or this one ... ;)- that allows the team of people working on a feature to work in splendid isolation until the feature is ready to get merged into a mainline release. So Lambda (& Jigsaw) are in their own Projects with their own hg forests. Note that Mike & Maurizio synced up the lambda forest with JDK 8 recently: http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004128.html so creating such builds should be easier then before, but given that neither Lambda nor the Mac Port are integrated into JDK 8, you'd have three fast moving parts to deal with, so it wouldn't necessarily be trivial: Just potentially a bit easier then a few weeks ago. ;) cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From henri.gomez at gmail.com Thu Nov 17 05:50:17 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 17 Nov 2011 14:50:17 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: <4EC51042.7010800@oracle.com> References: <4EC51042.7010800@oracle.com> Message-ID: > So Lambda (& Jigsaw) are in their own Projects with their own > hg forests. Note that Mike & Maurizio synced up the lambda forest > with JDK 8 recently: > http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004128.html > so creating such builds should be easier then before, but given that neither > Lambda nor the Mac Port are integrated into JDK 8, you'd have three fast > moving parts to deal with, so it wouldn't necessarily be trivial: > Just potentially a bit easier then a few weeks ago. ;) Any interest in having such 'labs/forest' available as package for OS/X users ? If so, advices more than welcomed From forax at univ-mlv.fr Thu Nov 17 06:10:36 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 17 Nov 2011 15:10:36 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: <4EC51042.7010800@oracle.com> Message-ID: <4EC515DC.1050803@univ-mlv.fr> On 11/17/2011 02:50 PM, Henri Gomez wrote: >> So Lambda (& Jigsaw) are in their own Projects with their own >> hg forests. Note that Mike& Maurizio synced up the lambda forest >> with JDK 8 recently: >> http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004128.html >> so creating such builds should be easier then before, but given that neither >> Lambda nor the Mac Port are integrated into JDK 8, you'd have three fast >> moving parts to deal with, so it wouldn't necessarily be trivial: >> Just potentially a bit easier then a few weeks ago. ;) > Any interest in having such 'labs/forest' available as package for OS/X users ? > If so, advices more than welcomed Hi Henry, I think having lambda + openjdk8 for Mac users will be cool, like you have it on windows and linux. http://jdk8.java.net/lambda/ As Dalibor said, you need to merge lambda workspace and MacPort workspace. R?mi From benjamin.john.evans at gmail.com Thu Nov 17 07:03:22 2011 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 17 Nov 2011 16:03:22 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: <4EC51042.7010800@oracle.com> Message-ID: Sounds like a great idea. Go for it, provided you have time / cycles. On Nov 17, 2011 2:50 PM, "Henri Gomez" wrote: > > So Lambda (& Jigsaw) are in their own Projects with their own > > hg forests. Note that Mike & Maurizio synced up the lambda forest > > with JDK 8 recently: > > > http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004128.html > > so creating such builds should be easier then before, but given that > neither > > Lambda nor the Mac Port are integrated into JDK 8, you'd have three fast > > moving parts to deal with, so it wouldn't necessarily be trivial: > > Just potentially a bit easier then a few weeks ago. ;) > > Any interest in having such 'labs/forest' available as package for OS/X > users ? > If so, advices more than welcomed > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111117/ca4b7dfc/attachment.html From henri.gomez at gmail.com Thu Nov 17 07:14:52 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 17 Nov 2011 16:14:52 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: <4EC51042.7010800@oracle.com> Message-ID: > Sounds like a great idea. Go for it, provided you have time / cycles. I saw many patches for OS/X MLVM. What about patches for http://jdk8.java.net/lambda/ ? From henri.gomez at gmail.com Thu Nov 17 10:27:13 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 17 Nov 2011 19:27:13 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: <4EC51042.7010800@oracle.com> References: <4EC51042.7010800@oracle.com> Message-ID: > Yeah, in general in OpenJDK we tend to create new Projects for new > major features (like a mac port, or this one ... ;)- that allows > the team of people working on a feature to work in splendid isolation > until the feature is ready to get merged into a mainline release. > > So Lambda (& Jigsaw) are in their own Projects with their own > hg forests. Note that Mike & Maurizio synced up the lambda forest > with JDK 8 recently: > http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004128.html > so creating such builds should be easier then before, but given that neither > Lambda nor the Mac Port are integrated into JDK 8, you'd have three fast > moving parts to deal with, so it wouldn't necessarily be trivial: > Just potentially a bit easier then a few weeks ago. ;) For Lambda on OS/X, a bsd-port (ie: without Cocoa) should be enough. From dalibor.topic at oracle.com Thu Nov 17 10:49:06 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 17 Nov 2011 19:49:06 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: <4EC51042.7010800@oracle.com> Message-ID: <4EC55722.8070805@oracle.com> Part of the challenge will be that 8 is a quickly moving target, lambda is synced with 8 sporadically, and mac port is based on 7, (and in the future 7u) which is a quickly moving target, diverging from 8, obviously. My suggestion would be to start by looking at the diff between 7 and mac port, and then applying that to a variant of the lambda forest. If you want to in addition follow mlvm and jdk8 in flight, I would not underestimate the integration effort necessary to make it all work as expected (rather then just build;). cheers, dalibor topic On 11/17/11 4:03 PM, Ben Evans wrote: > Sounds like a great idea. Go for it, provided you have time / cycles. > > On Nov 17, 2011 2:50 PM, "Henri Gomez" > wrote: > > > So Lambda (& Jigsaw) are in their own Projects with their own > > hg forests. Note that Mike & Maurizio synced up the lambda forest > > with JDK 8 recently: > > http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004128.html > > so creating such builds should be easier then before, but given that neither > > Lambda nor the Mac Port are integrated into JDK 8, you'd have three fast > > moving parts to deal with, so it wouldn't necessarily be trivial: > > Just potentially a bit easier then a few weeks ago. ;) > > Any interest in having such 'labs/forest' available as package for OS/X users ? > If so, advices more than welcomed > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From brian.goetz at oracle.com Thu Nov 17 13:35:56 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 17 Nov 2011 22:35:56 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: References: Message-ID: <0C2D4EE8-60B4-4B7A-A7C7-76FD9DD7DC39@oracle.com> > My understanding is that lambdas are currently a separate hg forest > (to allow the lambdas team to go faster), and that the team will be > bringing code across from lambdas into jdk8 mainline, and then > rebaselining. > > So it may not be possible to build a combined jdk8 + lambdas at the > moment. (Brian, please correct me if I'm wrong). Not trivially. But, the changes in the lambda forest are almost exclusively to the compiler and adding new library classes; we pull from jdk8 to lambda regularly. No Hotspot changes, or changes to existing libraries. So such a merge should be quite practical. From henri.gomez at gmail.com Thu Nov 17 23:01:30 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Fri, 18 Nov 2011 08:01:30 +0100 Subject: OpenJDK 8 + lambdas build for OS X In-Reply-To: <0C2D4EE8-60B4-4B7A-A7C7-76FD9DD7DC39@oracle.com> References: <0C2D4EE8-60B4-4B7A-A7C7-76FD9DD7DC39@oracle.com> Message-ID: 2011/11/17 Brian Goetz : >> My understanding is that lambdas are currently a separate hg forest >> (to allow the lambdas team to go faster), and that the team will be >> bringing code across from lambdas into jdk8 mainline, and then >> rebaselining. >> >> So it may not be possible to build a combined jdk8 + lambdas at the >> moment. (Brian, please correct me if I'm wrong). > > Not trivially. > > But, the changes in the lambda forest are almost exclusively to the compiler and adding new library classes; we pull from jdk8 to lambda regularly. ?No Hotspot changes, or changes to existing libraries. ?So such a merge should be quite practical. As I said, I'd like to try with a bsd-port, not the full Cocoa / MacOSX port From astrange at apple.com Wed Nov 23 22:36:21 2011 From: astrange at apple.com (Alexander Strange) Date: Thu, 24 Nov 2011 01:36:21 -0500 Subject: Illegal Instruction in debug_build In-Reply-To: <83D80E9F-5946-4922-9929-C35CDA0094DE@oracle.com> References: <3A0D0B72-80EF-4DDB-ABCE-E5AC79637E0B@oracle.com> <83D80E9F-5946-4922-9929-C35CDA0094DE@oracle.com> Message-ID: <3B08A452-FD2F-44C0-963B-0031B95A5524@apple.com> I assume this thread is discussing building something besides macosx-port on OS X. I fixed this in the debug build in macosx-port hotspot here: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/51d10977410a Your code seems to be failing because of a compiler bug. That said, the LLVM developers recommend against the use of register variables. On Oct 15, 2011, at 7:23 PM, John Rose wrote: > I don't know the ins and outs of asm and grabbing rsp on Mac, but the OS X port group probably know something about it. -- John > > On Oct 15, 2011, at 8:49 AM, Michael Barker wrote: > >> Good luck! > > Thanks. I found where the problem is, it's in the > os::current_stack_pointer method in os_bsd_x86.cpp and it depends on > level of compilation. If I compile the code below without > optimisation e.g.: > > #include > > class os { > public: > void* current_stack_pointer(); > }; > > void* os::current_stack_pointer() { > register void *esp __asm__ ("rsp"); > return esp; > } > > int main() { > os o = os(); > printf("%p\n", o.current_stack_pointer()); > } > > # g++ test.cc -o test > > It will generate the following assembly: > > __ZN2os21current_stack_pointerEv: > 0000000000000000 pushq %rbp > 0000000000000001 movq %rsp,%rbp > 0000000000000004 movq %rdi,0xf8(%rbp) > 0000000000000008 movq 0xe0(%rbp),%rax > 000000000000000c movq %rax,%rsp > 000000000000000f movq %rsp,%rax > 0000000000000012 movq %rax,0xe8(%rbp) > 0000000000000016 movq 0xe8(%rbp),%rax > 000000000000001a movq %rax,0xf0(%rbp) > 000000000000001e movq 0xf0(%rbp),%rax > 0000000000000022 popq %rbp > > And will fail with an illegal instruction. If optimisation is added > (-O1 is sufficient) it works fine: > > # g++ -O1 test.cc -o test > > And the generated assembly looks far more sane: > > 0000000000000000 pushq %rbp > 0000000000000001 movq %rsp,%rbp > 0000000000000004 movq %rsp,%rax > 0000000000000007 popq %rbp > 0000000000000008 ret > > So I've added -01 to the debug flags in > hotspot/make/bsd/makefiles/gcc.make and it now seems to run okay. I'm > not sure that it's the best fix. Is there are better way to get hold > of the stack pointer? I.e. one that doesn't get stomped over by a > lack of optimisation :-). Not sure if this specific to Mac OS 7 or > gcc 4.2. > > Mike. > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From mikeb01 at gmail.com Thu Nov 24 01:00:48 2011 From: mikeb01 at gmail.com (Michael Barker) Date: Thu, 24 Nov 2011 09:00:48 +0000 Subject: Illegal Instruction in debug_build In-Reply-To: <3B08A452-FD2F-44C0-963B-0031B95A5524@apple.com> References: <3A0D0B72-80EF-4DDB-ABCE-E5AC79637E0B@oracle.com> <83D80E9F-5946-4922-9929-C35CDA0094DE@oracle.com> <3B08A452-FD2F-44C0-963B-0031B95A5524@apple.com> Message-ID: Hi, Yes I'm compiling mlvm which is a set of patches on the hotspot tree. I noticed that fix has recently made it's way through to the hotspot branch. However, I'm compiling against gcc 4.2 therefore the compiler falls through to the default case on the ifdef and hits the illegal instruction bug. The fix I'm using locally looks like: address os::current_stack_pointer() { #if defined(SPARC_WORKS) register void *esp; __asm__("mov %%"SPELL_REG_SP", %0":"=r"(esp)); return (address) ((char*)esp + sizeof(long)*2); #else register void *esp; __asm__("mov %%"SPELL_REG_SP", %0":"=r"(esp)); return (address) esp; #endif } And similar for "_get_previous_fp()" in os_bsd_x86.cpp. I'm not sure what the correct fix is here. Should I be using clang instead of gcc 4.2 or should there be an additional option on the #ifdef, e.g. if defined(__clang__) || defined(__llvm__) || defined(__gcc42__)? Mike. On Thu, Nov 24, 2011 at 6:36 AM, Alexander Strange wrote: > I assume this thread is discussing building something besides macosx-port on OS X. > > I fixed this in the debug build in macosx-port hotspot here: > http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/51d10977410a > > Your code seems to be failing because of a compiler bug. That said, the LLVM developers recommend against the use of register variables. > > On Oct 15, 2011, at 7:23 PM, John Rose wrote: > >> I don't know the ins and outs of asm and grabbing rsp on Mac, but the OS X port group probably know something about it. ?-- John >> >> On Oct 15, 2011, at 8:49 AM, Michael Barker wrote: >> >>> Good luck! >> >> Thanks. ?I found where the problem is, it's in the >> os::current_stack_pointer method in os_bsd_x86.cpp and it depends on >> level of compilation. ?If I compile the code below without >> optimisation e.g.: >> >> #include >> >> class os { >> public: >> ? void* current_stack_pointer(); >> }; >> >> void* os::current_stack_pointer() { >> register void *esp __asm__ ("rsp"); >> return esp; >> } >> >> int main() { >> os o = os(); >> printf("%p\n", o.current_stack_pointer()); >> } >> >> # g++ test.cc -o test >> >> It will generate the following assembly: >> >> __ZN2os21current_stack_pointerEv: >> 0000000000000000 ? ? ?pushq ? %rbp >> 0000000000000001 ? ? ?movq ? ?%rsp,%rbp >> 0000000000000004 ? ? ?movq ? ?%rdi,0xf8(%rbp) >> 0000000000000008 ? ? ?movq ? ?0xe0(%rbp),%rax >> 000000000000000c ? ? ?movq ? ?%rax,%rsp >> 000000000000000f ? ? ?movq ? ?%rsp,%rax >> 0000000000000012 ? ? ?movq ? ?%rax,0xe8(%rbp) >> 0000000000000016 ? ? ?movq ? ?0xe8(%rbp),%rax >> 000000000000001a ? ? ?movq ? ?%rax,0xf0(%rbp) >> 000000000000001e ? ? ?movq ? ?0xf0(%rbp),%rax >> 0000000000000022 ? ? ?popq ? ?%rbp >> >> And will fail with an illegal instruction. ?If optimisation is added >> (-O1 is sufficient) it works fine: >> >> # g++ -O1 test.cc -o test >> >> And the generated assembly looks far more sane: >> >> 0000000000000000 ? ? ?pushq ? %rbp >> 0000000000000001 ? ? ?movq ? ?%rsp,%rbp >> 0000000000000004 ? ? ?movq ? ?%rsp,%rax >> 0000000000000007 ? ? ?popq ? ?%rbp >> 0000000000000008 ? ? ?ret >> >> So I've added -01 to the debug flags in >> hotspot/make/bsd/makefiles/gcc.make and it now seems to run okay. ?I'm >> not sure that it's the best fix. ?Is there are better way to get hold >> of the stack pointer? ?I.e. one that doesn't get stomped over by a >> lack of optimisation :-). ?Not sure if this specific to Mac OS 7 or >> gcc 4.2. >> >> Mike. >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From mroos at roos.com Sat Nov 26 22:16:42 2011 From: mroos at roos.com (Mark Roos) Date: Sat, 26 Nov 2011 22:16:42 -0800 Subject: Implementing a Smalltalk debugger with JSR292 Message-ID: One of the key parts of Smalltalk is the 'live' debugger. Unlike the general dynamic language features which are well supported by the additions from JSR292 the debugger requires support which may not have been considered as necessary to support dynamic languages. So we were not sure we would be able to provide that portion of the Smalltalk experience on the jvm. The good news is that we were able to implement almost all of the Smalltalk debugger features using only the services provided in the released jdk7. I thought I would take a moment to describe how we did it to both demonstrate the approach and to solicit suggestions for improvements. The Smalltalk debugger is 'live' in that it exists as a separate thread within the same process/memory space as the thread being debugged. This allows one to manipulate and inspect all objects from the same viewpoint as the debugged thread. Smalltalk offers the ability to inspect all instances of a class(type), all references to a specific object, the variables on all levels of the stack, senders and implementers of methods, and the ability to single step through method sends. There is also the ability to restart a thread from any level of the stack but we opted to wait on the coro patch before implementing this ( I also don't use it as it can have quite a few side effects ). The approach we took has two facets, we ( mainly oscar ) coded a C++ jvmti agent with a JNI interface which allowed us to call some JVMTI apis from within the jvm being debugged and we added some logic to the callsite to handle the stepping. Implementers and senders of methods is handled via reflection on the classes and methods present so that was easy. To support all instances and all references requires heap inspection which we get from using the jvmti heap functions. This had some issues with some of the support classes for invoke dynamic but we were able to use a two pass tagging approach to make sure we found all of the references to our objects. This has to find objects both in arrays and in instance vars. Inspecting the stack was straight forward once we filtered the stack trace to only have our method sends present. As an option one can also inspect the full jvm trace. Using the jvmti variable access api allows the locating the variable which is then placed into a static field of out debugger support class. This field is then access by Smallltalk via a primitive (in Smalltalk a primitive is the way we share with the underlying environment). Once we have this object we can manipulate its instance vars from the Smalltalk side as well. When an error is thrown the thread is suspended ( we added some jvmti thread management apis just to get away from the deprecated methods) and a new thread is launched with an instance of the debugger and a pointer to the thread to debug. At this point one can only inspect the thread locals and anything else in the object memory. The thread is not restartable so we kill it ( by sending ThreadDeath ). But it the error is a halt or breakpoint we can then step the thread along. We tried this with jvmti but is was broken and seems to add quite a bit of delay to everything. Plus its a callback approach which looked like a lot of work. So instead we tweaked the call site logic to add a debug check. I liked the way this worked a lot. For a dynamic look up we already have a callsite with a target of one or more GWTs to select the implementation which matches the receiver class. What we have to do to implement a debugger is to place before the first GWT a test which determines if this is the time to suspend. Unfortunately GWTs are added to the end so we need a way to keep the test at the beginning (thanks to John and R?me suggestion) we can simply have a callsite have a target which is another callsite. The first callsite points at the test logic and the second gets the GWT chain. One nice thing is that we can revert to the single site version using a debug flag. The code to get the initial target for the bootstrap callsite looks like: private void setBootstrapTarget(MethodHandle mh){ // get the appropriate initial call site sequence if( RtDebugger._debugEnable){ // for debugging we need to have a sequence of methodHandles that is always the first // code executed when a callsite is invoked. This checks to see if we should // hold here for a debug step or continue. _realSite = new MutableCallSite(mh); // this is the extra call site to hold the gwts MethodHandle invoker = _realSite.dynamicInvoker(); MethodHandles.Lookup lookup=MethodHandles.lookup(); MethodHandle debugEntry= null; MethodType mt=MethodType.methodType(void.class, RtObject.class); try { debugEntry = lookup.findStatic(RtDebugger.class, "debugEntry", mt); } catch (Throwable e) { e.printStackTrace(); } invoker = MethodHandles.foldArguments(invoker , debugEntry); // does nothing except suspend if necessary _realSite.setTarget(mh); this.setTarget(invoker); }else{ // normal behavior is to just use the RtCallSite to hold the GWT chain as its target this.setTarget(mh); } } The debug test code tests for the correct thread and for the stack depth ( jvmti api) and looks like: public static void debugEntry(RtObject arg){ if(_debugThread == Thread.currentThread()){ if(getStackSize(_debugThread) <= _debugDepth){ // send debugger update notice notifyDebugStep(); suspendThreadPrim(_debugThread); } } } As you can see it did not take much code ( lots of thinking though ) to implement a stepping debugger. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111126/5e7e847b/attachment.html From eller.helmut at gmail.com Sun Nov 27 01:07:50 2011 From: eller.helmut at gmail.com (Helmut Eller) Date: Sun, 27 Nov 2011 10:07:50 +0100 Subject: Implementing a Smalltalk debugger with JSR292 References: Message-ID: * Mark Roos [2011-11-27 06:16] writes: > The approach we took has two facets, we ( mainly oscar ) coded a C++ > jvmti agent with a JNI interface which allowed us to call some JVMTI > apis from within the jvm being debugged and we added some logic to the > callsite to handle the stepping. What's the cost of this approach? In a previous post you said that enabling the debug agent degraded performance of the JVM considerably. If the debugger enabled in "production mode"? How does the efficiency of your system compare to native Smalltalks? Helmut From forax at univ-mlv.fr Sun Nov 27 02:03:13 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 27 Nov 2011 11:03:13 +0100 Subject: Implementing a Smalltalk debugger with JSR292 In-Reply-To: References: Message-ID: <4ED20AE1.6030005@univ-mlv.fr> On 11/27/2011 07:16 AM, Mark Roos wrote: > One of the key parts of Smalltalk is the 'live' debugger. Unlike the > general dynamic language features which > are well supported by the additions from JSR292 the debugger requires > support which may not have been considered > as necessary to support dynamic languages. So we were not sure we > would be able to provide that portion > of the Smalltalk experience on the jvm. > > The good news is that we were able to implement almost all of the > Smalltalk debugger features using only the > services provided in the released jdk7. I thought I would take a > moment to describe how we did it to both > demonstrate the approach and to solicit suggestions for improvements. > > The Smalltalk debugger is 'live' in that it exists as a separate > thread within the same process/memory space as the > thread being debugged. This allows one to manipulate and inspect all > objects from the same viewpoint as the > debugged thread. Smalltalk offers the ability to inspect all > instances of a class(type), all references to a specific > object, the variables on all levels of the stack, senders and > implementers of methods, and the ability to single step > through method sends. There is also the ability to restart a thread > from any level of the stack but we opted to > wait on the coro patch before implementing this ( I also don't use it > as it can have quite a few side effects ). > > The approach we took has two facets, we ( mainly oscar ) coded a C++ > jvmti agent with a JNI interface which allowed > us to call some JVMTI apis from within the jvm being debugged and we > added some logic to the callsite to handle the > stepping. > > Implementers and senders of methods is handled via reflection on the > classes and methods present so that was easy. > > To support all instances and all references requires heap inspection > which we get from using the jvmti heap functions. > This had some issues with some of the support classes for invoke > dynamic but we were able to use a two pass tagging > approach to make sure we found all of the references to our objects. > This has to find objects both in arrays and in > instance vars. > > Inspecting the stack was straight forward once we filtered the stack > trace to only have our method sends present. As > an option one can also inspect the full jvm trace. Using the jvmti > variable access api allows the locating the variable > which is then placed into a static field of out debugger support > class. This field is then access by Smallltalk via a > primitive (in Smalltalk a primitive is the way we share with the > underlying environment). Once we have this object > we can manipulate its instance vars from the Smalltalk side as well. > > When an error is thrown the thread is suspended ( we added some jvmti > thread management apis just to get away > from the deprecated methods) and a new thread is launched with an > instance of the debugger and a pointer to the > thread to debug. At this point one can only inspect the thread locals > and anything else in the object memory. The > thread is not restartable so we kill it ( by sending ThreadDeath ). > > But it the error is a halt or breakpoint we can then step the thread > along. We tried this with jvmti but is was broken > and seems to add quite a bit of delay to everything. Plus its a > callback approach which looked like a lot of work. So > instead we tweaked the call site logic to add a debug check. I liked > the way this worked a lot. > > For a dynamic look up we already have a callsite with a target of one > or more GWTs to select the implementation > which matches the receiver class. What we have to do to implement a > debugger is to place before the first GWT > a test which determines if this is the time to suspend. Unfortunately > GWTs are added to the end so we need a > way to keep the test at the beginning (thanks to John and R?me > suggestion) we can simply have a callsite have a target which > is another callsite. The first callsite points at the test logic and > the second gets the GWT chain. One nice thing > is that we can revert to the single site version using a debug flag. > > The code to get the initial target for the bootstrap callsite looks > like: > *private**void*setBootstrapTarget(MethodHandle mh){ > // get the appropriate initial call site sequence > *if*( RtDebugger./_debugEnable/){ > // for debugging we need to have a sequence of methodHandles that is > always the first > // code executed when a _callsite_ is invoked. This checks to see if > we should > // hold here for a debug step or continue. > _realSite= *new*MutableCallSite(mh); // this is the extra call site > to hold the gwts > MethodHandle invoker = _realSite.dynamicInvoker(); > MethodHandles.Lookup lookup=MethodHandles./lookup/(); > MethodHandle debugEntry= *null*; > MethodType mt=MethodType./methodType/(*void*.*class*, > RtObject.*class*); > *try*{ > debugEntry = lookup.findStatic(RtDebugger.*class*, > "debugEntry", mt); > } > *catch*(Throwable e) { > e.printStackTrace(); > } > invoker = MethodHandles./foldArguments/(invoker , debugEntry); > // does nothing except suspend if necessary > _realSite.setTarget(mh); > *this*.setTarget(invoker); > }*else*{ > // normal behavior is to just use the RtCallSite to hold the GWT chain > as its target > *this*.setTarget(mh); > } > } > > The debug test code tests for the correct thread and for the stack > depth ( jvmti api) and looks like: > *public**static**void*debugEntry(RtObject arg){ > *if*(/_debugThread/== Thread./currentThread/()){ > *if*(/getStackSize/(/_debugThread/) <= /_debugDepth/){ > // send debugger update notice > /notifyDebugStep/(); > /suspendThreadPrim/(/_debugThread/); > } > } > } > > As you can see it did not take much code ( lots of thinking though ) > to implement a stepping debugger. A small remark, you can do the findStatic to find debugEntry once and store the resulting method handle,in a static final field. Also, here you choose to launch your application or in debugging mode or in non-debugging mode, there is a way to choose if you want to debug at runtime without paying a cost (in fact you pay something if the code is run by the interpreter but not in the JITed code) if the debugger is never started. You can install a SwitchPoint guard in front all your targets and no call to debugEntry by default. When the debugger is launched, you invalidate the SwitchPoint and re-install your debugEntry call in front of all target with a new SwitchPoint in front of that. When the debugging session is done, you can switch off the new SwitchPoint to remove all call to debugEntry i.e. invalidate all targets that do the debugEntry check and re-install a new SwitchPoint with no call to debugEntry until the debugger is started again. So you will only pay the price of the debugger only during the debugging session. > > regards > mark cheers, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111127/007a5dd9/attachment-0001.html From mroos at roos.com Sun Nov 27 16:00:55 2011 From: mroos at roos.com (Mark Roos) Date: Sun, 27 Nov 2011 16:00:55 -0800 Subject: Implementing a Smalltalk debugger with JSR292 In-Reply-To: References: Message-ID: Hi Helmut, The problem I saw before was due to enabling all of the capabilities of jvmti. Since then I backed off to only the capabilities I use. With this change my original benchmarks do not show any slowdown. This was one of the reasons I chose to try this approach to stepping rather than use jvmti. There is still the question of does adding the debug test in front of every call add much time. This is on my list of things to find out. As to how Rtalk( mine) compares with Smalltalk. Well that really depends on the benchmark chosen. The big issue I see is my decision to use boxed integers for all uses vs the use of primitive integers by both the jvm and Smalltalk. For my Hanoi benchmark ( lots of ints ) I run about 10x slower than Smalltalk ( vs java being 50% faster than Smalltalk). But if I code in java as Rtalk does by using boxed integers hidden within other objects the java time becomes 5x slower than Smalltalk. So I think some looking at the use of integers would be the big benchmark gain. Some easy things would be an integer cache (as garbage is a big part of the time lost) and having the compiler use primitives for hidden loop counters and iterators. Having said that, for complex applications which spend lots of time in primitives ( string handling and float vectors) Rtalk is actually faster than Smalltalk. My application is a DSL compiler with a runtime which spend most of its time handling byteArrays and floatVectors so I am expecting to see the jvm version being faster. An added advantage I see is the ability to use java as the language to write user primitives in. This would make implementing local speed up methods quite easy I will let you know as it progresses regards mark mlvm-dev-bounces at openjdk.java.net wrote on 11/27/2011 01:07:50 AM: > From: Helmut Eller > To: mlvm-dev at openjdk.java.net > Date: 11/27/2011 01:24 AM > Subject: Re: Implementing a Smalltalk debugger with JSR292 > Sent by: mlvm-dev-bounces at openjdk.java.net > > * Mark Roos [2011-11-27 06:16] writes: > > > The approach we took has two facets, we ( mainly oscar ) coded a C++ > > jvmti agent with a JNI interface which allowed us to call some JVMTI > > apis from within the jvm being debugged and we added some logic to the > > callsite to handle the stepping. > > What's the cost of this approach? In a previous post you said that > enabling the debug agent degraded performance of the JVM considerably. > If the debugger enabled in "production mode"? How does the efficiency > of your system compare to native Smalltalks? > > Helmut > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111127/52442e16/attachment.html From mroos at roos.com Sun Nov 27 16:00:55 2011 From: mroos at roos.com (Mark Roos) Date: Sun, 27 Nov 2011 16:00:55 -0800 Subject: Implementing a Smalltalk debugger with JSR292 In-Reply-To: <4ED20AE1.6030005@univ-mlv.fr> References: <4ED20AE1.6030005@univ-mlv.fr> Message-ID: Hi R?mi Thanks for the comments. I like the idea of using switchPoints and have been thinking about them both for this and for the general purpose of method invalidation. Right now I keep a list of all callsites and when necessary I dump them all. I thought of replacing this with a switchpoint but then I lose the ability to selectively invalidate ( by selector usually ) unless I have a switchpoint per selector. I have some experiments planned to compare the approaches. thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111127/2ae581b8/attachment.html From headius at headius.com Tue Nov 29 00:12:47 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 29 Nov 2011 02:12:47 -0600 Subject: Forkable OpenJDK...is it madness? Message-ID: Ok, hypothetical situation. What if a patch were crafted for OpenJDK that could make it possible to safely fork(2) the JVM process. What would it look like? Obviously VM-critical threads would have to be restarted. Such a thing is certainly possible; the Rubinius VM maintains background threads for JIT requests, etc, and before forking forces them to a safe point. After forking, they are resumed at with their original state. Could this be done for the OpenJDK worker threads? On a JVM I have just started, running jruby -e "sleep", I see the following non-userland threads: * DispatchQueue_1: com.apple.main-thread (serial) This is presumably the thread started up to handle Cocoa events. I assume there would be a way to re-start it on the other side. * The main thread This is the actual JVM "main" thread, and on my trace the stack tops out in the "sleep" monitor. We can assume this is the thread we want to survive forking. * Eight GC threads Possible to force them to a safe point and re-launch on the other side? The stacks they're sitting on are not very deep... * An unidentifier thread It looks like this...I'm not sure what this one is doing: 2597 java_start(Thread*) 2597 VMThread::run() 2597 VMThread::loop() 2597 Monitor::wait(bool, long, bool) 2597 Monitor::IWait(Thread*, long long) 2597 os::PlatformEvent::park(long long) 2597 _pthread_cond_wait 2597 __semwait_signal * Java: Reference Handler The java.lang.ref handler. Presumably this could also be restarted, since normally it sits there doing nothing...just waiting for work. * Java: Finalizer Again, a thread that normally does no work and could presumably be restarted. * Java: Signal Dispatcher This is certainly trickier, but I assume the same signal handling logic that works in the parent could be restarted in the child without a great deal of effort. * Two Java: C2 CompilerThread0 Normally not doing anything; presumably could be restarted. * Java: Service Thread * Another unknown thread These looks similar to the unknown thread above. I am guessing these threads are more OS X-specific stuff... ... So, most of the threads in question seem like they could be paused, saved off in some way, and restarted on the other side. Of course it's not that simple...I assume there's on-stack state that would need to be translated and bootstrapped in the child. I also assume the JVM has some intimate knowledge of memory layout that might go all wacky in the presence of fork. But is something like this feasible in theory? I ask because one of the biggest complaints from JRuby users is the inability to fork...not just for doing fork+exec-style process launching, but for initializing some state and preforking children. And JRuby's not alone. Dalvik supports forking, which is a large part of why it's able to boot small Java applications so darn quickly; the base Dalvik process has already initialized a bunch of VM and Android state, and the foked child just boots application-specific logic. I'm interested in finding a way to make this happen. - Charlie From fcassia at gmail.com Tue Nov 29 00:17:50 2011 From: fcassia at gmail.com (Fernando Cassia) Date: Tue, 29 Nov 2011 05:17:50 -0300 Subject: Forkable OpenJDK...is it madness? In-Reply-To: References: Message-ID: On Tue, Nov 29, 2011 at 05:12, Charles Oliver Nutter wrote: > And JRuby's not alone. Dalvik supports forking, which is a large part > of why it's able to boot small Java applications so darn quickly; the > base Dalvik process has already initialized a bunch of VM and Android > state, and the foked child just boots application-specific logic. > > I'm interested in finding a way to make this happen. > > - Charlie It exists, and it?s a work-around, but it works very well... nailgun. ;-) http://www.martiansoftware.com/nailgun/ FC -- "The purpose of computing is insight, not numbers." Richard Hamming - http://en.wikipedia.org/wiki/Hamming_code From headius at headius.com Tue Nov 29 00:30:18 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 29 Nov 2011 02:30:18 -0600 Subject: Forkable OpenJDK...is it madness? In-Reply-To: References: Message-ID: On Tue, Nov 29, 2011 at 2:17 AM, Fernando Cassia wrote: > It exists, and it?s a work-around, but it works very well... nailgun. ;-) > > http://www.martiansoftware.com/nailgun/ Nailgun is a fairly limited solution that isn't really comparable to fork: * There's no process isolation; one bad "nail" can seal the coffin. * There's no simple way to do prefork-style initialization; each "nail" must explicitly share the *same* in-memory resources, or initialize its own * Signal handling does not work properly across the nailgun process wire (could be improved, but it's still emulating signal handling atop a wire protocol) JRuby already ships with Nailgun, and we recommend it as a possible for solution to improve startup of quick tasks, but it's no fork. - Charlie From headius at headius.com Tue Nov 29 00:32:03 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 29 Nov 2011 02:32:03 -0600 Subject: Process-level fork on OpenJDK...is it madness? Message-ID: Just to make it clear here, I'm editing the subject...my interest is in "process forking", not "open source forking" :) - Charlie On Tue, Nov 29, 2011 at 2:12 AM, Charles Oliver Nutter wrote: > Ok, hypothetical situation. What if a patch were crafted for OpenJDK > that could make it possible to safely fork(2) the JVM process. What > would it look like? > > Obviously VM-critical threads would have to be restarted. Such a thing > is certainly possible; the Rubinius VM maintains background threads > for JIT requests, etc, and before forking forces them to a safe point. > After forking, they are resumed at with their original state. Could > this be done for the OpenJDK worker threads? > > On a JVM I have just started, running jruby -e "sleep", I see the > following non-userland threads: > > * DispatchQueue_1: com.apple.main-thread ?(serial) > > This is presumably the thread started up to handle Cocoa events. I > assume there would be a way to re-start it on the other side. > > * The main thread > > This is the actual JVM "main" thread, and on my trace the stack tops > out in the "sleep" monitor. We can assume this is the thread we want > to survive forking. > > * Eight GC threads > > Possible to force them to a safe point and re-launch on the other > side? The stacks they're sitting on are not very deep... > > * An unidentifier thread > > It looks like this...I'm not sure what this one is doing: > > ? ? ? ? ?2597 java_start(Thread*) > ? ? ? ? ? ?2597 VMThread::run() > ? ? ? ? ? ? ?2597 VMThread::loop() > ? ? ? ? ? ? ? ?2597 Monitor::wait(bool, long, bool) > ? ? ? ? ? ? ? ? ?2597 Monitor::IWait(Thread*, long long) > ? ? ? ? ? ? ? ? ? ?2597 os::PlatformEvent::park(long long) > ? ? ? ? ? ? ? ? ? ? ?2597 _pthread_cond_wait > ? ? ? ? ? ? ? ? ? ? ? ?2597 __semwait_signal > > * Java: Reference Handler > > The java.lang.ref handler. Presumably this could also be restarted, > since normally it sits there doing nothing...just waiting for work. > > * Java: Finalizer > > Again, a thread that normally does no work and could presumably be restarted. > > * Java: Signal Dispatcher > > This is certainly trickier, but I assume the same signal handling > logic that works in the parent could be restarted in the child without > a great deal of effort. > > * Two Java: C2 CompilerThread0 > > Normally not doing anything; presumably could be restarted. > > * Java: Service Thread > * Another unknown thread > > These looks similar to the unknown thread above. I am guessing these > threads are more OS X-specific stuff... > > ... > > So, most of the threads in question seem like they could be paused, > saved off in some way, and restarted on the other side. Of course it's > not that simple...I assume there's on-stack state that would need to > be translated and bootstrapped in the child. I also assume the JVM has > some intimate knowledge of memory layout that might go all wacky in > the presence of fork. But is something like this feasible in theory? > > I ask because one of the biggest complaints from JRuby users is the > inability to fork...not just for doing fork+exec-style process > launching, but for initializing some state and preforking children. > > And JRuby's not alone. Dalvik supports forking, which is a large part > of why it's able to boot small Java applications so darn quickly; the > base Dalvik process has already initialized a bunch of VM and Android > state, and the foked child just boots application-specific logic. > > I'm interested in finding a way to make this happen. > > - Charlie > From lukas.stadler at jku.at Tue Nov 29 04:58:02 2011 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Tue, 29 Nov 2011 12:58:02 +0000 Subject: hg: mlvm/mlvm/hotspot: coro: fix for stack walking displaced ricochet frames Message-ID: <20111129125803.3C3364748C@hg.openjdk.java.net> Changeset: a798eba1f10a Author: Lukas Stadler Date: 2011-11-29 13:57 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a798eba1f10a coro: fix for stack walking displaced ricochet frames ! coro.patch From lukas.stadler at jku.at Tue Nov 29 04:58:51 2011 From: lukas.stadler at jku.at (Lukas Stadler) Date: Tue, 29 Nov 2011 13:58:51 +0100 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> Message-ID: <4ED4D70B.3010509@jku.at> Uh, sorry for the long wait... That was another problem that occurs with invokedynamic, in particular with ricochet frames. I fixed it, pushed the changes and uploaded a new binary to http://ssw.jku.at/General/Staff/LS/coro/. - Lukas On 2011-11-07 00:18, Charles Oliver Nutter wrote: > Ok, bug report time! :) > > It looks like it's crashing again once Hotspot JITs. > > This works: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 100 100 > > But this doesn't: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 1000 100 > > Here's the console output, and I've attached the log. > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/frame_x86.cpp:312 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/Users/henri/Documents/jenkins/data/jobs/openjdk-1.8-bsdport-x86_64/workspace/sources/hotspot/src/cpu/x86/vm/frame_x86.cpp:312), > pid=21511, tid=4341268480 > # assert(sp()<= result + _displacement) failed: monitor end should > be above the stack pointer > # > # JRE version: 8.0 > # Java VM: OpenJDK 64-Bit Server VM (23.0-b03-fastdebug mixed mode > bsd-amd64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/headius/projects/jruby/hs_err_pid21511.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Current thread is 4341268480 > Dumping core ... > Abort trap > > - Charlie > > On Sun, Nov 6, 2011 at 6:35 PM, Henri Gomez wrote: >> Ok, I get them and coro is included in OpenJDK 8 from openjdk-osx-build >> >> 2011/11/6 Henri Gomez: >>> >>> Le 6 nov. 2011 ? 22:12, Henri Gomez a ?crit : >>> >>>> Hi to all, >>>> >>>> I'm looking for Coro patch by Lukas Stadler, any body knows where I can find it ? >>> More on this, I found patch here (http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ca450b9f8b56), but wondering if it's allready applied to trunk or in some patch area ? >>> >>> Thanks for your help/advices >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111129/767d78a9/attachment.html From headius at headius.com Tue Nov 29 12:02:08 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 29 Nov 2011 14:02:08 -0600 Subject: JRuby invokedynamic updates for November Message-ID: Hello friends! Just updating you on the status of JRuby + invokedynamic, for those of you following along. About halfway through this month I did another pass at getting tests passing with invokedynamic enabled, and finally turned on all uses (at the time) of indy in JRuby! Hooray! Last week, I finally enabled Ruby to Java dispatch via invokedynamic for single-arity methods as well. The performance on those calls appears to be about double what it was before...reflection is a harsh mistress. Last night, I added an experimental change to use invokedynamic for looking up Ruby instance variables. Ruby ivars are basically like a Map on every object, so we use various techniques to avoid storing an entire map. My hope is that an indy lookup path will be faster than the non-indy path...but so far, they're about equal. I have not enabled this on master, but it can be enabled by passing -Xinvokedynamic.cache.ivars=true to JRuby or -Djruby.invokedynamic.cache.ivars=true passed to Java. Invokedynamic is being used for the following: * Method dispatches from Ruby to Ruby with fixed-arity target methods that do not require heap frames * Method dispatches from Ruby to Java with fixed-arity target methods * Loads of literals and lazily-allocated runtime constructs * Constant lookups * Math and boolean operations where the right operand is a literal integer or float have special treatment Things are looking very good. Also recently, I modified how JRuby prints out configuration properties. All properties for invokedynamic should now be properly displayed by passing --properties to JRuby. Upcoming work includes getting Ruby methods with variable arity and heap frames to use invokedynamic, as well as Java methods with variable arity. Have fun! - Charlie From mroos at roos.com Tue Nov 29 13:32:17 2011 From: mroos at roos.com (Mark Roos) Date: Tue, 29 Nov 2011 13:32:17 -0800 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: References: Message-ID: Interesting. I guess if you could save that state to disk and reload it then you would have the equivalent of the Smalltalk image concept. Although it seems like this would be hard to be op sys neutral. It also seems it would help the warmup issue with Hotspot by preloadiing its counters etc. I just finished a paper (link below) on JVM startup time which states that for small programs its around 70ms. So I assume there is some other startup time you are trying to improve? Or is the paper not applicable to the launching of a new process as you describe it? I would think that someway to serialize application state would be more interesting than an complete clone of java memory and the following restart. As I recall from the Smalltalk image code the big issue was not the threads but was with all of the op sys handles that need to be reconstituted. I look forward to the responses mark www.mii.lt/olympiads_in_informatics/pdf/INFOL073.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111129/f63309a4/attachment.html From fcassia at gmail.com Tue Nov 29 14:03:56 2011 From: fcassia at gmail.com (Fernando Cassia) Date: Tue, 29 Nov 2011 19:03:56 -0300 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: References: Message-ID: On Tue, Nov 29, 2011 at 18:32, Mark Roos wrote: > I just finished a paper (link below) on JVM startup time which states that > for small programs its around > 70ms I don?t know about your paper, but on my single-core Atom netbook with 1.6 Ghz CPU and 2 Gigs of RAM running WinXP SP3 and JRE 7.0, starting Jython takes a whopping 10-20 seconds... even more the first time I think. But I admit that might be more an issue with Jython than the JVM... Plus, if start-up time of small apps wasn?t an issue Nailgun wouldn?t even be needed. :) FC -- "The purpose of computing is insight, not numbers." Richard Hamming - http://en.wikipedia.org/wiki/Hamming_code From blackdrag at gmx.org Tue Nov 29 14:22:11 2011 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 29 Nov 2011 23:22:11 +0100 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: References: Message-ID: <4ED55B13.5090803@gmx.org> Am 29.11.2011 22:32, schrieb Mark Roos: [...] > I just finished a paper (link below) on JVM startup time which states > that for small programs its around > 70ms. So I assume there is some other startup time you are trying to > improve? Or is the > paper not applicable to the launching of a new process as you describe it? For the JVM itself that might be true, but in case of for example Groovy there is a lot if init work to be done before the first program can be executed. And this takes time. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From thomas.wuerthinger at oracle.com Tue Nov 29 14:34:43 2011 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 29 Nov 2011 23:34:43 +0100 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: <4ED55B13.5090803@gmx.org> References: <4ED55B13.5090803@gmx.org> Message-ID: <4ED55E03.90905@oracle.com> On 11/29/11 11:22 PM, Jochen Theodorou wrote: > Am 29.11.2011 22:32, schrieb Mark Roos: > [...] >> I just finished a paper (link below) on JVM startup time which states >> that for small programs its around >> 70ms. So I assume there is some other startup time you are trying to >> improve? Or is the >> paper not applicable to the launching of a new process as you describe it? > For the JVM itself that might be true, but in case of for example Groovy > there is a lot if init work to be done before the first program can be > executed. And this takes time. > > bye Jochen What kind of initialization work is this? Could the result of that work be cached? - thomas From headius at headius.com Tue Nov 29 14:54:18 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 29 Nov 2011 16:54:18 -0600 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: <4ED55E03.90905@oracle.com> References: <4ED55B13.5090803@gmx.org> <4ED55E03.90905@oracle.com> Message-ID: On Tue, Nov 29, 2011 at 4:34 PM, Thomas Wuerthinger wrote: > What kind of initialization work is this? Could the result of that work > be cached? I can describe the work done in JRuby's boot. We have managed to get JRuby's basic runtime to start up pretty fast; about 0.3 to 0.5s on my high-end MBP. However on other systems, especially on 64-bit Linux, startup time is still quite a bit slower. The Apple JDK does an amazing job of speeding startup that no other builds seem to have matched yet. JRuby's base init involves: * Constructing metaclasses for all the core Ruby classes like String, Array, etc. It's difficult or impossible to cache this because they are essentially key/value tables of pointers to methods...in our case, thousands of tiny classes that subclass DynamicMethod. * Initializing native bindings for POSIX features. Loading the libffi binding dynamically and programmatically wiring up all the functions we use takes a bit of startup time. * Loading additional .rb sources from classloader resources. Parts of JRuby (more and more) are implemented in Ruby; as a result, we have to load a bunch of Ruby code on boot. The bigger part of startup is loading all the third-party libraries that a user might need in their app. Those sources need to be parsed every time, turned into an AST, and partially executed to boot. All the code that does parsing and interpretation is cold initially, and so we have slow startup no matter what we do. We have experimented with serializing the parse tree or precompiling to bytecode, but neither case was actually faster than our parser. If the JVM had the ability to fork, users could potentially boot a baseline application image and then fork instances from that to run iterative tests, etc, rather than having to re-boot the entire runtime and application's dependencies every time. I'm also looking into the possibility of doing this on Dalvik; we could keep a running JRuby image in memory and then fork off that for JRuby-based applications, reducing startup time significantly. - Charlie From blackdrag at gmx.org Tue Nov 29 15:10:47 2011 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 30 Nov 2011 00:10:47 +0100 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: <4ED55E03.90905@oracle.com> References: <4ED55B13.5090803@gmx.org> <4ED55E03.90905@oracle.com> Message-ID: <4ED56677.4060707@gmx.org> Am 29.11.2011 23:34, schrieb Thomas Wuerthinger: > On 11/29/11 11:22 PM, Jochen Theodorou wrote: >> Am 29.11.2011 22:32, schrieb Mark Roos: >> [...] >>> I just finished a paper (link below) on JVM startup time which states >>> that for small programs its around >>> 70ms. So I assume there is some other startup time you are trying to >>> improve? Or is the >>> paper not applicable to the launching of a new process as you describe it? >> For the JVM itself that might be true, but in case of for example Groovy >> there is a lot if init work to be done before the first program can be >> executed. And this takes time. >> >> bye Jochen > What kind of initialization work is this? Could the result of that work > be cached? we have to setup the initial meta class system, which requires to use reflection to inspect some classes and other work. Yes, this could be cached, if we would know how. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From headius at headius.com Tue Nov 29 19:01:36 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 29 Nov 2011 21:01:36 -0600 Subject: Coro patch In-Reply-To: <4ED4D70B.3010509@jku.at> References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> Message-ID: Awesome, thanks Lukas! Hopefully when the next openjdk-osx-build runs, it will pick up these changes, and we'll have a working coro impl on OS X too :) - Charlie On Tue, Nov 29, 2011 at 6:58 AM, Lukas Stadler wrote: > Uh, sorry for the long wait... > That was another problem that occurs with invokedynamic, in particular with > ricochet frames. > I fixed it, pushed the changes and uploaded a new binary to > http://ssw.jku.at/General/Staff/LS/coro/. > > -? Lukas > > > On 2011-11-07 00:18, Charles Oliver Nutter wrote: > > Ok, bug report time! :) > > It looks like it's crashing again once Hotspot JITs. > > This works: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 100 100 > > But this doesn't: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 1000 100 > > Here's the console output, and I've attached the log. > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/frame_x86.cpp:312 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/Users/henri/Documents/jenkins/data/jobs/openjdk-1.8-bsdport-x86_64/workspace/sources/hotspot/src/cpu/x86/vm/frame_x86.cpp:312), > pid=21511, tid=4341268480 > # assert(sp() <= result + _displacement) failed: monitor end should > be above the stack pointer > # > # JRE version: 8.0 > # Java VM: OpenJDK 64-Bit Server VM (23.0-b03-fastdebug mixed mode > bsd-amd64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/headius/projects/jruby/hs_err_pid21511.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Current thread is 4341268480 > Dumping core ... > Abort trap > > - Charlie > > On Sun, Nov 6, 2011 at 6:35 PM, Henri Gomez wrote: > > Ok, I get them and coro is included in OpenJDK 8 from openjdk-osx-build > > 2011/11/6 Henri Gomez : > > Le 6 nov. 2011 ? 22:12, Henri Gomez a ?crit : > > Hi to all, > > I'm looking for Coro patch by Lukas Stadler, any body knows where I can find > it ? > > More on this, I found patch here > (http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ca450b9f8b56), but wondering > if it's allready applied to trunk or in some patch area ? > > Thanks for your help/advices > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From henri.gomez at gmail.com Tue Nov 29 23:00:45 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 08:00:45 +0100 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> Message-ID: > Awesome, thanks Lukas! > > Hopefully when the next openjdk-osx-build runs, it will pick up these > changes, and we'll have a working coro impl on OS X too :) Oops, forgot to tweet about it yesterday. http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-20111129-release.dmg Cheers From henri.gomez at gmail.com Tue Nov 29 23:05:59 2011 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 30 Nov 2011 08:05:59 +0100 Subject: tags & co Message-ID: Hi to all, When building OpenJDK 8 yesterday, I could see in hg logs : Changes 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Summary: Fixed several EA issues with Connection Graph construction. Reviewed-by: never, twisti (detail / hgweb) coro: fix for stack walking displaced ricochet frames (detail / hgweb) Added tag jdk8-b14 for changeset 23aa7f2c80a2 (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Added tag jdk8-b13 for changeset 26fb81a1e9ce (detail / hgweb) Added tag jdk8-b12 for changeset 8e2104d565ba (detail / hgweb) BTW, when I goes into sources directory and use hg tags, I get : tip 374:9cb255745863 qtip 374:9cb255745863 qbase 374:9cb255745863 jdk7-b147-to-bsd-port.patch 374:9cb255745863 jdk8-b11 372:1defbc57940a jdk8-b10 371:a6c4c248e8fa jdk8-b09 370:8adb70647b5a jdk8-b08 369:fb1bc13260d7 jdk8-b07 363:0db7ae9f2b10 If I goes into jdk subdir, I get hg tags reports : tip 4749:8eea3d274bfd qtip 4749:8eea3d274bfd coro.patch 4749:8eea3d274bfd anonk.patch 4748:38876cc39669 continuation.patch 4747:c99046535b7c meth-experiment.patch 4746:d491995b281a meth.patch 4745:92efb3787399 cval-tune-7030453.patch 4744:0fc880c23c30 meth-acc-7077803.patch 4743:3ed82c30d87c qbase 4742:93e37b71947e jdk7-b147-to-bsd-port.patch 4742:93e37b71947e jdk8-b14 4729:99632935785e jdk8-b13 4673:4cb2e8679b27 jdk8-b12 4663:09fd2067f715 Question, should I get tags info from jdk subdir to get the correct tag number ? Cheers From headius at headius.com Tue Nov 29 23:46:42 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 01:46:42 -0600 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> Message-ID: Ok, good news and not as good news! The good news is that coro seems to be working in the latest openjdk-osx-build, and it definitely improves JRuby's coroutine performance! For running bench_fiber_ring with 100 fibers passing 1000 messages, here's numbers for the threaded impl: 100 fibers / 1000 passes: 1.070000 0.000000 1.070000 ( 1.071000) 100 fibers / 1000 passes: 1.070000 0.000000 1.070000 ( 1.070000) 100 fibers / 1000 passes: 1.092000 0.000000 1.092000 ( 1.092000) 100 fibers / 1000 passes: 1.077000 0.000000 1.077000 ( 1.077000) And with the coro impl: 100 fibers / 1000 passes: 0.215000 0.000000 0.215000 ( 0.215000) 100 fibers / 1000 passes: 0.217000 0.000000 0.217000 ( 0.217000) 100 fibers / 1000 passes: 0.212000 0.000000 0.212000 ( 0.212000) 100 fibers / 1000 passes: 0.216000 0.000000 0.216000 ( 0.215000) Hooray! Now for the not-as-good news... Here's Ruby 1.9.3 on the same benchmark: 100 fibers / 1000 passes: 0.160000 0.000000 0.160000 ( 0.155562) 100 fibers / 1000 passes: 0.150000 0.000000 0.150000 ( 0.156581) 100 fibers / 1000 passes: 0.160000 0.000000 0.160000 ( 0.155351) 100 fibers / 1000 passes: 0.150000 0.000000 0.150000 ( 0.156776) Now even getting close to 1.9.3 is really awesome, but I'm wondering if either I'm doing something wrong (maybe broke something in the coro-based fiber impl?) or if something regressed in coro, because Lukas's blog post showed JRuby + coro performing significantly *better* than C Ruby. This is also a bit tricky to profile...since call stacks are jumping around a bit :) A dumb sampled profile doesn't show much other than Ruby code being hit heavily...which I'd expect. Lukas: Are you able to reproduce these numbers with JRuby master and bench/bench_fiber_ring.rb? Here's the command line I'm using: jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 20 100 1000 - Charlie From headius at headius.com Tue Nov 29 23:49:52 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 01:49:52 -0600 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> Message-ID: Seconds after I email...A DISCOVERY... It seems like invokedynamic is causing headaches for coro. Here's the numbers with coro fibers and JRuby's invokedynamic support turned *off*: 100 fibers / 1000 passes: 0.076000 0.000000 0.076000 ( 0.077000) 100 fibers / 1000 passes: 0.076000 0.000000 0.076000 ( 0.076000) 100 fibers / 1000 passes: 0.105000 0.000000 0.105000 ( 0.105000) 100 fibers / 1000 passes: 0.070000 0.000000 0.070000 ( 0.070000) Perhaps the fix you (Lukas) made to get coro + indy working together has impacted performance? Awesome, awesome, awesome to see the above perf numbers...regardless! - Charlie On Wed, Nov 30, 2011 at 1:46 AM, Charles Oliver Nutter wrote: > Ok, good news and not as good news! > > The good news is that coro seems to be working in the latest > openjdk-osx-build, and it definitely improves JRuby's coroutine > performance! > > For running bench_fiber_ring with 100 fibers passing 1000 messages, > here's numbers for the threaded impl: > > 100 fibers / 1000 passes: ? 1.070000 ? 0.000000 ? 1.070000 ( ?1.071000) > 100 fibers / 1000 passes: ? 1.070000 ? 0.000000 ? 1.070000 ( ?1.070000) > 100 fibers / 1000 passes: ? 1.092000 ? 0.000000 ? 1.092000 ( ?1.092000) > 100 fibers / 1000 passes: ? 1.077000 ? 0.000000 ? 1.077000 ( ?1.077000) > > And with the coro impl: > > 100 fibers / 1000 passes: ? 0.215000 ? 0.000000 ? 0.215000 ( ?0.215000) > 100 fibers / 1000 passes: ? 0.217000 ? 0.000000 ? 0.217000 ( ?0.217000) > 100 fibers / 1000 passes: ? 0.212000 ? 0.000000 ? 0.212000 ( ?0.212000) > 100 fibers / 1000 passes: ? 0.216000 ? 0.000000 ? 0.216000 ( ?0.215000) > > Hooray! > > Now for the not-as-good news... > > Here's Ruby 1.9.3 on the same benchmark: > > 100 fibers / 1000 passes: ? 0.160000 ? 0.000000 ? 0.160000 ( ?0.155562) > 100 fibers / 1000 passes: ? 0.150000 ? 0.000000 ? 0.150000 ( ?0.156581) > 100 fibers / 1000 passes: ? 0.160000 ? 0.000000 ? 0.160000 ( ?0.155351) > 100 fibers / 1000 passes: ? 0.150000 ? 0.000000 ? 0.150000 ( ?0.156776) > > Now even getting close to 1.9.3 is really awesome, but I'm wondering > if either I'm doing something wrong (maybe broke something in the > coro-based fiber impl?) or if something regressed in coro, because > Lukas's blog post showed JRuby + coro performing significantly > *better* than C Ruby. > > This is also a bit tricky to profile...since call stacks are jumping > around a bit :) A dumb sampled profile doesn't show much other than > Ruby code being hit heavily...which I'd expect. > > Lukas: Are you able to reproduce these numbers with JRuby master and > bench/bench_fiber_ring.rb? Here's the command line I'm using: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 20 100 1000 > > - Charlie From george.marrows at ge.com Wed Nov 30 01:36:27 2011 From: george.marrows at ge.com (Marrows, George A (GE Energy)) Date: Wed, 30 Nov 2011 10:36:27 +0100 Subject: JRuby startup costs [was: Process-level fork on OpenJDK...is it madness?] Message-ID: Hi Charlie - could you explain this a little more? > The bigger part of startup is loading all the third-party libraries > that a user might need in their app. Those sources need to be parsed > every time, turned into an AST, and partially executed to boot. All > the code that does parsing and interpretation is cold initially, and > so we have slow startup no matter what we do. > > We have experimented with serializing the parse tree or precompiling > to bytecode, but neither case was actually faster than our parser. Are you saying that ruby source on disk -> parse tree in memory -> bytecode in JVM takes the same amount of time as bytecode on disk -> bytecode in JVM ? If so, how do you think that is? Or just that any difference is lost as noise in the bigger start-up cost? -- George From lukas.stadler at jku.at Wed Nov 30 02:17:26 2011 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 30 Nov 2011 11:17:26 +0100 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> Message-ID: <4ED602B6.10101@jku.at> On 2011-11-30 08:49, Charles Oliver Nutter wrote: > Seconds after I email...A DISCOVERY... > > It seems like invokedynamic is causing headaches for coro. Here's the > numbers with coro fibers and JRuby's invokedynamic support turned > *off*: > > 100 fibers / 1000 passes: 0.076000 0.000000 0.076000 ( 0.077000) > 100 fibers / 1000 passes: 0.076000 0.000000 0.076000 ( 0.076000) > 100 fibers / 1000 passes: 0.105000 0.000000 0.105000 ( 0.105000) > 100 fibers / 1000 passes: 0.070000 0.000000 0.070000 ( 0.070000) > > Perhaps the fix you (Lukas) made to get coro + indy working together > has impacted performance? Hm, maybe... the fix was really just a tiny tiny bugfix, so that shouldn't have caused any performance regressions, although, of course, I can't say for sure. But maybe something in invokedynamic has changed so that it's impacted by coro? I can reproduce it and I'll have to look into this. Has your usage of invokedynamic changed a lot since the last "perfect" performance numbers with invokedynamic? - Lukas > Awesome, awesome, awesome to see the above perf numbers...regardless! > > - Charlie > > On Wed, Nov 30, 2011 at 1:46 AM, Charles Oliver Nutter > wrote: >> Ok, good news and not as good news! >> >> The good news is that coro seems to be working in the latest >> openjdk-osx-build, and it definitely improves JRuby's coroutine >> performance! >> >> For running bench_fiber_ring with 100 fibers passing 1000 messages, >> here's numbers for the threaded impl: >> >> 100 fibers / 1000 passes: 1.070000 0.000000 1.070000 ( 1.071000) >> 100 fibers / 1000 passes: 1.070000 0.000000 1.070000 ( 1.070000) >> 100 fibers / 1000 passes: 1.092000 0.000000 1.092000 ( 1.092000) >> 100 fibers / 1000 passes: 1.077000 0.000000 1.077000 ( 1.077000) >> >> And with the coro impl: >> >> 100 fibers / 1000 passes: 0.215000 0.000000 0.215000 ( 0.215000) >> 100 fibers / 1000 passes: 0.217000 0.000000 0.217000 ( 0.217000) >> 100 fibers / 1000 passes: 0.212000 0.000000 0.212000 ( 0.212000) >> 100 fibers / 1000 passes: 0.216000 0.000000 0.216000 ( 0.215000) >> >> Hooray! >> >> Now for the not-as-good news... >> >> Here's Ruby 1.9.3 on the same benchmark: >> >> 100 fibers / 1000 passes: 0.160000 0.000000 0.160000 ( 0.155562) >> 100 fibers / 1000 passes: 0.150000 0.000000 0.150000 ( 0.156581) >> 100 fibers / 1000 passes: 0.160000 0.000000 0.160000 ( 0.155351) >> 100 fibers / 1000 passes: 0.150000 0.000000 0.150000 ( 0.156776) >> >> Now even getting close to 1.9.3 is really awesome, but I'm wondering >> if either I'm doing something wrong (maybe broke something in the >> coro-based fiber impl?) or if something regressed in coro, because >> Lukas's blog post showed JRuby + coro performing significantly >> *better* than C Ruby. >> >> This is also a bit tricky to profile...since call stacks are jumping >> around a bit :) A dumb sampled profile doesn't show much other than >> Ruby code being hit heavily...which I'd expect. >> >> Lukas: Are you able to reproduce these numbers with JRuby master and >> bench/bench_fiber_ring.rb? Here's the command line I'm using: >> >> jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 20 100 1000 >> >> - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From headius at headius.com Wed Nov 30 02:18:58 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 04:18:58 -0600 Subject: JRuby startup costs [was: Process-level fork on OpenJDK...is it madness?] In-Reply-To: References: Message-ID: On Wed, Nov 30, 2011 at 3:36 AM, Marrows, George A (GE Energy) > Are you saying that > ?ruby source on disk -> parse tree in memory -> bytecode in JVM > takes the same amount of time as > ?bytecode on disk -> bytecode in JVM > ? If so, how do you think that is? Actually, since JRuby has an interpreter, the comparison is: a) ruby source to AST, start interpreting versus b) bytecode on disk to bytecode in memory, JVM interprets The problem we've seen in (b) is that while bytecode can load quickly, bytecode *verification* is considerably more costly than our parser. We can get the AST up and running more quickly than the JVM can load and verify bytecode. Another more subtle aspect is that our interpreter gets "hot" *very* quickly, since it's running the same code over and over again regardless of what Ruby code is executing. If all that Ruby code were JVM bytecode, each piece would have to get "hot" to run fast...so interpreting wins there too. > Or just that any difference is lost as noise in the bigger start-up > cost? Over the longer-term startup, things get a little muddy. We know that JVM warmup is a factor, but even if we run multiple app startups in the same process (using something like Nailgun) we still don't boot as fast as we'd like. So there's probably more we can fix in the load process for large apps, as well as exploring things like preforking. - Charlie From headius at headius.com Wed Nov 30 02:20:51 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 04:20:51 -0600 Subject: Coro patch In-Reply-To: <4ED602B6.10101@jku.at> References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> <4ED602B6.10101@jku.at> Message-ID: On Wed, Nov 30, 2011 at 4:17 AM, Lukas Stadler wrote: > Hm, maybe... the fix was really just a tiny tiny bugfix, so that > shouldn't have caused any performance regressions, although, of course, > I can't say for sure. > But maybe something in invokedynamic has changed so that it's impacted > by coro? I can reproduce it and I'll have to look into this. I have not looked at compiler logs for indy at all...if you don't suspect that indy is interfering with coro, then perhaps the execution pattern is preventing indy from optimizing as well as it should. > Has your usage of invokedynamic changed a lot since the last "perfect" > performance numbers with invokedynamic? The numbers on your blog would not have been using invokedynamic at all. What other numbers are you referring to? JRuby is using invokedynamic more and more, but we're not doing anything *unusual*. - Charlie From lukas.stadler at jku.at Wed Nov 30 02:37:20 2011 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 30 Nov 2011 11:37:20 +0100 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> <4ED602B6.10101@jku.at> Message-ID: <4ED60760.5080401@jku.at> On 2011-11-30 11:20, Charles Oliver Nutter wrote: > On Wed, Nov 30, 2011 at 4:17 AM, Lukas Stadler wrote: >> Hm, maybe... the fix was really just a tiny tiny bugfix, so that >> shouldn't have caused any performance regressions, although, of course, >> I can't say for sure. >> But maybe something in invokedynamic has changed so that it's impacted >> by coro? I can reproduce it and I'll have to look into this. > I have not looked at compiler logs for indy at all...if you don't > suspect that indy is interfering with coro, then perhaps the execution > pattern is preventing indy from optimizing as well as it should. Exactly. It's still a bug in the coro patch, since it shouldn't impact performance that way. >> Has your usage of invokedynamic changed a lot since the last "perfect" >> performance numbers with invokedynamic? > The numbers on your blog would not have been using invokedynamic at > all. What other numbers are you referring to? > > JRuby is using invokedynamic more and more, but we're not doing > anything *unusual*. I thought that maybe you were refering to a measurement with indy that showed the better numbers. But I guess it wouldn't have been a sudden decline in performance anyway, since it's probably not one specific use of indy that exposes the coro performance regression, but all of them together. - Lukas From forax at univ-mlv.fr Wed Nov 30 05:02:16 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 30 Nov 2011 14:02:16 +0100 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: <4ED56677.4060707@gmx.org> References: <4ED55B13.5090803@gmx.org> <4ED55E03.90905@oracle.com> <4ED56677.4060707@gmx.org> Message-ID: <4ED62958.3020307@univ-mlv.fr> On 11/30/2011 12:10 AM, Jochen Theodorou wrote: > Am 29.11.2011 23:34, schrieb Thomas Wuerthinger: >> On 11/29/11 11:22 PM, Jochen Theodorou wrote: >>> Am 29.11.2011 22:32, schrieb Mark Roos: >>> [...] >>>> I just finished a paper (link below) on JVM startup time which states >>>> that for small programs its around >>>> 70ms. So I assume there is some other startup time you are trying to >>>> improve? Or is the >>>> paper not applicable to the launching of a new process as you describe it? >>> For the JVM itself that might be true, but in case of for example Groovy >>> there is a lot if init work to be done before the first program can be >>> executed. And this takes time. >>> >>> bye Jochen >> What kind of initialization work is this? Could the result of that work >> be cached? > we have to setup the initial meta class system, which requires to use > reflection to inspect some classes and other work. Yes, this could be > cached, if we would know how. It worth to give a try to java.lang.ClassValue, here. You you be able to create your metaclass only when needed. Also note that you can also lazyly initialize the list of methods, fields etc. because even if two threads ask the same list at the same time, the result will be the same, so there is no need to use synchronized here. (this is exactly what java.lang.Class code does) : > > bye Jochen > cheers, R?mi From blackdrag at gmx.org Wed Nov 30 07:28:56 2011 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 30 Nov 2011 16:28:56 +0100 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: <4ED62958.3020307@univ-mlv.fr> References: <4ED55B13.5090803@gmx.org> <4ED55E03.90905@oracle.com> <4ED56677.4060707@gmx.org> <4ED62958.3020307@univ-mlv.fr> Message-ID: <4ED64BB8.30207@gmx.org> Am 30.11.2011 14:02, schrieb R?mi Forax: [...] >>> What kind of initialization work is this? Could the result of that work >>> be cached? >> we have to setup the initial meta class system, which requires to use >> reflection to inspect some classes and other work. Yes, this could be >> cached, if we would know how. > > It worth to give a try to java.lang.ClassValue, here. > You you be able to create your metaclass only when needed. > > Also note that you can also lazyly initialize the list of methods, > fields etc. because even if two threads ask the same list at the > same time, the result will be the same, so there is no need > to use synchronized here. > (this is exactly what java.lang.Class code does) : it is all lazy, but what gives it if you need it for even the most simple script? For println 1+1 you will need the a meta class for the current class, you will need the int meta class, you will need to load the default methods too... and one second is burnt. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From mroos at roos.com Wed Nov 30 09:57:05 2011 From: mroos at roos.com (Mark Roos) Date: Wed, 30 Nov 2011 09:57:05 -0800 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> Message-ID: Hi Charles Interesting results. Is your code for the coro implementation available somewhere to look at? thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111130/9fab297c/attachment.html From stephen.bannasch at deanbrook.org Wed Nov 30 12:03:50 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 30 Nov 2011 15:03:50 -0500 Subject: JRuby invokedynamic updates for November In-Reply-To: References: Message-ID: Hi Charlie, Is your latest work going on in the indy_update branch? I have a simple Ruby xml processing benchmark that compares several Ruby XML libraries including rexml which is part of the Ruby standard library. My test measures the time to do the following 100 times: - open 98k XML document and count one type of leaf element (466 entries) On the latest master version of JRuby the performance of rexml degrades dramatically using Java 1.7 and even more using mlvm. java rexml ------------------------------------------ 1.6.0_27 3.8 1.7.0 24.7 (recent macosx-port) 1.8.0 72.1 (mlvm today) Using the indy_update branch of JRuby however I get MUCH better results on 1.7 java rexml ------------------------------------------ 1.6.0_27 4.6 1.7.0 4.3 (recent macosx-port) 1.8.0 ** error, see below ** Exception in thread "main" java.lang.ExceptionInInitializerError at org.jruby.Main.(Main.java:87) at org.jruby.Main.main(Main.java:125) Caused by: java.lang.RuntimeException: unsupported Java version: 1.8 at org.jruby.RubyInstanceConfig.(RubyInstanceConfig.java:365) ... 2 more Benchmark code here: https://gist.github.com/1410423 From headius at headius.com Wed Nov 30 12:42:21 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 14:42:21 -0600 Subject: JRuby invokedynamic updates for November In-Reply-To: References: Message-ID: On Wed, Nov 30, 2011 at 2:03 PM, Stephen Bannasch wrote: > Hi Charlie, > > Is your latest work going on in the indy_update branch? No, that's old stuff. I should wipe it out. I can explain your perf issue below, though. > I have a simple Ruby xml processing benchmark that compares several Ruby XML libraries including rexml which is part of the > Ruby standard library. > > My test measures the time to do the following 100 times: > > - open 98k XML document and count one type of leaf element (466 entries) > > On the latest master version of JRuby the performance of rexml degrades dramatically using Java 1.7 and even more using mlvm. ... > Using the indy_update branch of JRuby however I get MUCH better results on 1.7 I'll take a guess and say you're running this against OpenJDK 7 GA, right? The GA release was feature-complete, but a number of indy features were implemented in weakly-optimized or unoptimized ways. For example, a *critically* important feature for JRuby's invokedynamic support -- SwitchPoint -- is just a full-on volatile read every time you traverse the guard. I could enumerate the other issues with the GA release's optimzation, but if you poke around the bug listings for u2 you'll see the important JSR-292 improvements...most of which were initiated by my performance testing in JRuby. If you use one of the Java 7u2 early access releases (and there's builds of them called "OpenJDK 8" for OS X now) you should see substantially better performance across the board. - Charlie From headius at headius.com Wed Nov 30 12:43:44 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 14:43:44 -0600 Subject: JRuby invokedynamic updates for November In-Reply-To: References: Message-ID: I should add that if you're running this against a u2ish build and seeing poor performance, we need to talk. I'm not seeing that locally, and you shouldn't see it either. - Charlie On Wed, Nov 30, 2011 at 2:42 PM, Charles Oliver Nutter wrote: > On Wed, Nov 30, 2011 at 2:03 PM, Stephen Bannasch > wrote: >> Hi Charlie, >> >> Is your latest work going on in the indy_update branch? > > No, that's old stuff. I should wipe it out. I can explain your perf > issue below, though. > >> I have a simple Ruby xml processing benchmark that compares several Ruby XML libraries including rexml which is part of the >> Ruby standard library. >> >> My test measures the time to do the following 100 times: >> >> - open 98k XML document and count one type of leaf element (466 entries) >> >> On the latest master version of JRuby the performance of rexml degrades dramatically using Java 1.7 and even more using mlvm. > ... >> Using the indy_update branch of JRuby however I get MUCH better results on 1.7 > > I'll take a guess and say you're running this against OpenJDK 7 GA, > right? The GA release was feature-complete, but a number of indy > features were implemented in weakly-optimized or unoptimized ways. For > example, a *critically* important feature for JRuby's invokedynamic > support -- SwitchPoint -- is just a full-on volatile read every time > you traverse the guard. I could enumerate the other issues with the GA > release's optimzation, but if you poke around the bug listings for u2 > you'll see the important JSR-292 improvements...most of which were > initiated by my performance testing in JRuby. > > If you use one of the Java 7u2 early access releases (and there's > builds of them called "OpenJDK 8" for OS X now) you should see > substantially better performance across the board. > > - Charlie From headius at headius.com Wed Nov 30 12:47:18 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 14:47:18 -0600 Subject: Coro patch In-Reply-To: References: <9B961DA2-1064-4F14-8BCF-F94173C107BD@gmail.com> <4ED4D70B.3010509@jku.at> Message-ID: On Wed, Nov 30, 2011 at 11:57 AM, Mark Roos wrote: > Hi Charles > > Interesting results. ?Is your code for the coro implementation available > somewhere > to look at? On master and jruby-1_6 branch, under src/org/jruby/ext/fiber/CoroutineFiber.java. It's Lukas's code, mostly. https://github.com/jruby/jruby - Charlie From stephen.bannasch at deanbrook.org Wed Nov 30 13:27:42 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 30 Nov 2011 16:27:42 -0500 Subject: JRuby invokedynamic updates for November In-Reply-To: References: Message-ID: At 2:43 PM -0600 11/30/11, Charles Oliver Nutter wrote: >I should add that if you're running this against a u2ish build and >seeing poor performance, we need to talk. I'm not seeing that locally, >and you shouldn't see it either. Here's what I am testing with: Java 1.6.0_27 and macosx-port and mlvm built today. MLVM is patched on top of: http://hg.openjdk.java.net/hsx/hotspot-comp The following tests are all based on this JRuby commit in the master branch: $ git log -1 commit 49bb5f73dfc48080254a27ebc858d3639bd5dc2d Author: Charles Oliver Nutter Date: Wed Nov 30 04:33:36 2011 -0600 Remove unused import. Java 1.6.0_27, JRuby master branch $ jruby xml_benchmarks.rb Ruby version: jruby 1.7.0.dev (ruby-1.8.7-p352) (2011-11-30 49bb5f7) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_27) [darwin-x86_64-java] 100 times: Open 98k XML document and count one type of leaf element (466 entries) running benchmark once. Rehearsal --------------------------------------------------------- rexml 6.385000 0.000000 6.385000 ( 6.385000) hpricot 1.177000 0.000000 1.177000 ( 1.177000) jdom_document_builder 1.226000 0.000000 1.226000 ( 1.226000) nokogiri 2.105000 0.000000 2.105000 ( 2.105000) ----------------------------------------------- total: 10.893000sec user system total real rexml 3.957000 0.000000 3.957000 ( 3.957000) hpricot 0.460000 0.000000 0.460000 ( 0.459000) jdom_document_builder 0.234000 0.000000 0.234000 ( 0.234000) nokogiri 0.378000 0.000000 0.378000 ( 0.378000 http://hg.openjdk.java.net/macosx-port/macosx-port built today, JRuby master branch $ jruby xml_benchmarks.rb Ruby version: jruby 1.7.0.dev (ruby-1.8.7-p352) (2011-11-30 49bb5f7) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java] 100 times: Open 98k XML document and count one type of leaf element (466 entries) running benchmark once. Rehearsal --------------------------------------------------------- rexml 28.917000 0.000000 28.917000 ( 28.917000) hpricot 2.226000 0.000000 2.226000 ( 2.226000) jdom_document_builder 1.372000 0.000000 1.372000 ( 1.372000) nokogiri 2.448000 0.000000 2.448000 ( 2.448000) ----------------------------------------------- total: 34.963000sec user system total real rexml 28.005000 0.000000 28.005000 ( 28.005000) hpricot 2.211000 0.000000 2.211000 ( 2.211000) jdom_document_builder 0.264000 0.000000 0.264000 ( 0.264000) nokogiri 0.457000 0.000000 0.457000 ( 0.457000) MLVM built today: $ jruby xml_benchmarks.rb Ruby version: jruby 1.7.0.dev (ruby-1.8.7-p352) (2011-11-30 49bb5f7) (OpenJDK 64-Bit Server VM 1.8.0-internal) [darwin-amd64-java] 100 times: Open 98k XML document and count one type of leaf element (466 entries) running benchmark once. Rehearsal --------------------------------------------------------- rexml 65.205000 0.000000 65.205000 ( 65.205000) hpricot 4.433000 0.000000 4.433000 ( 4.433000) jdom_document_builder 1.375000 0.000000 1.375000 ( 1.374000) nokogiri 2.029000 0.000000 2.029000 ( 2.029000) ----------------------------------------------- total: 73.042000sec user system total real rexml 73.540000 0.000000 73.540000 ( 73.540000) hpricot 6.483000 0.000000 6.483000 ( 6.483000) jdom_document_builder 0.245000 0.000000 0.245000 ( 0.245000) nokogiri 0.433000 0.000000 0.433000 ( 0.433000) From headius at headius.com Wed Nov 30 15:25:54 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 17:25:54 -0600 Subject: JRuby invokedynamic updates for November In-Reply-To: References: Message-ID: On Wed, Nov 30, 2011 at 3:27 PM, Stephen Bannasch wrote: > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?user ? ? system ? ? ?total ? ? ? ?real > ?rexml ? ? ? ? ? ? ? ? ?73.540000 ? 0.000000 ?73.540000 ( 73.540000) > ?hpricot ? ? ? ? ? ? ? ? 6.483000 ?0.000000 ? 6.483000 ( ?6.483000) > ?jdom_document_builder ? 0.245000 ? 0.000000 ? 0.245000 ( ?0.245000) > ?nokogiri ? ? ? ? ? ? ? ?0.433000 ? 0.000000 ? 0.433000 ( ?0.433000) Ok, that's *incredibly* bad. Do you have the script you're using so I can reproduce the results here? Something's broken. - Charlie From forax at univ-mlv.fr Wed Nov 30 15:35:30 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 01 Dec 2011 00:35:30 +0100 Subject: Process-level fork on OpenJDK...is it madness? In-Reply-To: <4ED64BB8.30207@gmx.org> References: <4ED55B13.5090803@gmx.org> <4ED55E03.90905@oracle.com> <4ED56677.4060707@gmx.org> <4ED62958.3020307@univ-mlv.fr> <4ED64BB8.30207@gmx.org> Message-ID: <4ED6BDC2.9060908@univ-mlv.fr> On 11/30/2011 04:28 PM, Jochen Theodorou wrote: > Am 30.11.2011 14:02, schrieb R?mi Forax: > [...] >>>> What kind of initialization work is this? Could the result of that work >>>> be cached? >>> we have to setup the initial meta class system, which requires to use >>> reflection to inspect some classes and other work. Yes, this could be >>> cached, if we would know how. >> It worth to give a try to java.lang.ClassValue, here. >> You you be able to create your metaclass only when needed. >> >> Also note that you can also lazyly initialize the list of methods, >> fields etc. because even if two threads ask the same list at the >> same time, the result will be the same, so there is no need >> to use synchronized here. >> (this is exactly what java.lang.Class code does) : > it is all lazy, but what gives it if you need it for even the most > simple script? For > > println 1+1 > > you will need the a meta class for the current class, you will need the > int meta class, you will need to load the default methods too... and one > second is burnt. The only way I see to avoid that is to not load the meta-class until someone reference them so you can compile this example to System.out.println(2) and if there is a ref to a meta-class somewhere, discard the code and recompile it with meta-class check. I do something like that in PHP.reboot but my unit of compilation is the method and not the class, which also avoid to compile a code you never use. > > bye Jochen > R?mi From headius at headius.com Wed Nov 30 15:40:45 2011 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 30 Nov 2011 17:40:45 -0600 Subject: JRuby invokedynamic updates for November In-Reply-To: References: Message-ID: I may have found one big problem, using some rexml benchmarks I found. The instance-variable logic I just added seems like it might not be working right. It was supposed to be experimental and turned off, but I used the wrong flag. Invokedynamic disabled (-Xcompile.invokedynamic=false) Parsing small document for 5 seconds ... 5128 calls (1025.60/s) Adding new elemnt for 5 seconds ... 599104 calls (119820.80/s) Document creation for 5 seconds ... 105740 calls (21148.00/s) Writing tree for 5 seconds ... 6387 calls (1277.40/s) By-hand search for 5 seconds ... 319598 calls (63919.60/s) XPath search for 5 seconds ... 1319 calls (263.80/s) Parse large document for 5 seconds ... 367 calls (73.40/s) Stream parsing for 5 seconds ... 586 calls (117.20/s) Pull parsing for 5 seconds ... 622 calls (124.40/s) SAX2 parsing for 5 seconds ... 213 calls (42.60/s) Lightweight parsing for 5 seconds ... 787 calls (157.40/s) With instance var logic on: Parsing small document for 5 seconds ... 620 calls (124.00/s) Adding new elemnt for 5 seconds ... 538775 calls (107755.00/s) Document creation for 5 seconds ... 4457 calls (891.40/s) Writing tree for 5 seconds ... 1940 calls (388.00/s) By-hand search for 5 seconds ... 63180 calls (12636.00/s) XPath search for 5 seconds ... 104 calls (20.80/s) Parse large document for 5 seconds ... 31 calls (6.20/s) Stream parsing for 5 seconds ... 334 calls (66.80/s) Pull parsing for 5 seconds ... 336 calls (67.20/s) SAX2 parsing for 5 seconds ... 134 calls (26.80/s) Lightweight parsing for 5 seconds ... 426 calls (85.20/s) With instance var logic off: Parsing small document for 5 seconds ... 1179 calls (235.80/s) Adding new elemnt for 5 seconds ... 554026 calls (110805.40/s) Document creation for 5 seconds ... 112482 calls (22496.40/s) Writing tree for 5 seconds ... 8190 calls (1638.00/s) By-hand search for 5 seconds ... 415686 calls (83137.20/s) XPath search for 5 seconds ... 107 calls (21.40/s) Parse large document for 5 seconds ... 72 calls (14.40/s) Stream parsing for 5 seconds ... 332 calls (66.40/s) Pull parsing for 5 seconds ... 339 calls (67.80/s) SAX2 parsing for 5 seconds ... 133 calls (26.60/s) Lightweight parsing for 5 seconds ... 408 calls (81.60/s) The parsing cases are still slow, so there's something happening there. For those following along, the sampled profile (-Xprof, or --sample passed to JRuby) showed me that my instance variable fallback paths were getting hit heavily, which is how I figured out something's wrong there. - Charlie On Wed, Nov 30, 2011 at 5:25 PM, Charles Oliver Nutter wrote: > On Wed, Nov 30, 2011 at 3:27 PM, Stephen Bannasch > wrote: >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?user ? ? system ? ? ?total ? ? ? ?real >> ?rexml ? ? ? ? ? ? ? ? ?73.540000 ? 0.000000 ?73.540000 ( 73.540000) >> ?hpricot ? ? ? ? ? ? ? ? 6.483000 ?0.000000 ? 6.483000 ( ?6.483000) >> ?jdom_document_builder ? 0.245000 ? 0.000000 ? 0.245000 ( ?0.245000) >> ?nokogiri ? ? ? ? ? ? ? ?0.433000 ? 0.000000 ? 0.433000 ( ?0.433000) > > Ok, that's *incredibly* bad. Do you have the script you're using so I > can reproduce the results here? Something's broken. > > - Charlie From stephen.bannasch at deanbrook.org Wed Nov 30 19:52:43 2011 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 30 Nov 2011 22:52:43 -0500 Subject: JRuby invokedynamic updates for November In-Reply-To: References: Message-ID: At 5:25 PM -0600 11/30/11, Charles Oliver Nutter wrote: >On Wed, Nov 30, 2011 at 3:27 PM, Stephen Bannasch > wrote: >> user system total real >> rexml 73.540000 0.000000 73.540000 ( 73.540000) >> hpricot 6.483000 0.000000 6.483000 ( 6.483000) >> jdom_document_builder 0.245000 0.000000 0.245000 ( 0.245000) >> nokogiri 0.433000 0.000000 0.433000 ( 0.433000) > >Ok, that's *incredibly* bad. Do you have the script you're using so I >can reproduce the results here? Something's broken. > yup: At 3:03 PM -0500 11/30/11, Stephen Bannasch wrote: >Benchmark code here: https://gist.github.com/1410423 The hpricot benchmark is also slowed down consdierably.