From enevill at arm.com Thu Aug 13 01:45:59 2009 From: enevill at arm.com (Edward Nevill) Date: Thu, 13 Aug 2009 09:45:59 +0100 Subject: Interpreter Offsets (was RE: ARM Interpreter) In-Reply-To: <20090812120528.GH3241@redhat.com> References: <001601ca1b3a$d020bce0$706236a0$@com> <20090812120528.GH3241@redhat.com> Message-ID: <000001ca1bf2$7b8ec470$72ac4d50$@com> Note: I have cross-posted this to zero-dev which is where this discussion more logically belongs as it is not a packaging issue. I have left distro-pkg-dev on this post so people can see the discussion is moving to zero-dev, but please remove distro-pkg-dev from subsequent posts. >> > So my first question is why is everything conditionalized on >> > PRODUCT? Not being able to build not-PRODUCT means no assertions, >> > no debug helpers and no diagnostic options. I'd like to see all >> > these conditionals replaced with "#ifdef HOTSPOT_ASM". >> >> The reason everything is conditionalised on PRODUCT is that the Asm >> loop will not work with a non product build. This is because all the >> offsets in the structures change on a non product build because of >> the addition of debug info into the structures. > >That's really likely to break. Would it be possible to have a table >of all the constants you use, and fill it in at VM startup? The C++ >interpreter's init code (bytecodeInterpreter.cpp, around line 560) >would be a nice place. I saw you inlined ZeroFrame::SHARK_FRAME too, >that sort of thing could go there as well. That would be too expensive in terms of performance. Every time it needed to access a field it would need to load the offset from a table and then use that offset in another load. Note that there is a possible 2 cycle load use penalty between the two loads so this ends up taking 4 cycles instead of 1. The way to handle this is to write a tool which generates the offsets (called say 'mkoffsets'). You then in the build do something like gcc -o mkoffsets mkoffsets.cpp ./mkoffsets > offsets.s And the #include "offsets.s". As it happens there is an interface in OpenJDK for doing exactly this sort of thing. It is called VMStructs. I have written a version of mkoffsets.cpp using VMStructs (see below). I am not sure of the best way to handle the PRODUCT vs non PRODUCT issue. There are two possible approaches. 1) The first is to generate both sets of offsets in the build and use #ifdef PRODUCT to select the correct offsets. Eg. gcc -o mkoffsets mkoffsets.cpp -DPRODUCT ./mkoffsets > product_offsets.s gcc -o mkoffsets mkoffsets.cpp -DDEBUG ./mkoffsets > debug_offsets.s Then in the asm loop do #ifdef PRODUCT #include "product_offsets.s" #else #include "debug_offsets.s" #endif 2) The 2nd is to ensure that mkoffsets is 'cleaned' for every build so that if you switch between PRODUCT and non PRODUCT builds the offsets.s file always gets regenerated. I am leaning towards the first option as the consequences of the offsets file not being regenerated correctly are horrible. Regards, Ed. --- mkoffsets.cpp ------------------------------------------------- /* * Copyright 2009 Edward Nevill * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). */ #include "incls/_precompiled.incl" class VMStructs { public: static void print_vm_offsets(void); }; #define outfile stdout void print_def(const char *s, int v) { fprintf(outfile, "#define %-40s 0x%02x\n", s, v); } void nl(void) { fputc('\n', outfile); } void VMStructs::print_vm_offsets(void) { print_def("THREAD_PENDING_EXC", offset_of(JavaThread, _pending_exception)); print_def("THREAD_SUSPEND_FLAGS", offset_of(JavaThread, _suspend_flags)); print_def("THREAD_ACTIVE_HANDLES", offset_of(JavaThread, _active_handles)); print_def("THREAD_LAST_HANDLE_MARK", offset_of(JavaThread, _last_handle_mark)); print_def("THREAD_TLAB_TOP", offset_of(JavaThread, _tlab) + offset_of(ThreadLocalAllocBuffer, _top)); print_def("THREAD_TLAB_END", offset_of(JavaThread, _tlab) + offset_of(ThreadLocalAllocBuffer, _end)); print_def("THREAD_RESOURCEAREA", offset_of(JavaThread, _resource_area)); print_def("THREAD_HANDLE_AREA", offset_of(JavaThread, _handle_area)); print_def("THREAD_STACK_BASE", offset_of(JavaThread, _stack_base)); print_def("THREAD_STACK_SIZE", offset_of(JavaThread, _stack_size)); print_def("THREAD_LAST_JAVA_SP", offset_of(JavaThread, _anchor) + offset_of(JavaFrameAnchor, _last_Java_sp)); print_def("THREAD_JNI_ENVIRONMENT", offset_of(JavaThread, _jni_environment)); print_def("THREAD_VM_RESULT", offset_of(JavaThread, _vm_result)); print_def("THREAD_STATE", offset_of(JavaThread, _thread_state)); print_def("THREAD_DO_NOT_UNLOCK", offset_of(JavaThread, _do_not_unlock_if_synchronized)); print_def("THREAD_JAVA_STACK_BASE", offset_of(JavaThread, _zero_stack) + ZeroStack::base_offset()); print_def("THREAD_JAVA_SP", offset_of(JavaThread, _zero_stack) + ZeroStack::sp_offset()); print_def("THREAD_TOP_ZERO_FRAME", offset_of(JavaThread, _top_zero_frame)); } int main(void) { print_def("JVM_CONSTANT_Utf8", JVM_CONSTANT_Utf8); print_def("JVM_CONSTANT_Unicode", JVM_CONSTANT_Unicode); print_def("JVM_CONSTANT_Float", JVM_CONSTANT_Float); print_def("JVM_CONSTANT_Long", JVM_CONSTANT_Long); print_def("JVM_CONSTANT_Double", JVM_CONSTANT_Double); print_def("JVM_CONSTANT_Class", JVM_CONSTANT_Class); print_def("JVM_CONSTANT_String", JVM_CONSTANT_String); print_def("JVM_CONSTANT_Fieldref", JVM_CONSTANT_Fieldref); print_def("JVM_CONSTANT_Methodref", JVM_CONSTANT_Methodref); print_def("JVM_CONSTANT_InterfaceMethodref", JVM_CONSTANT_InterfaceMethodref); print_def("JVM_CONSTANT_NameAndType", JVM_CONSTANT_NameAndType); nl(); print_def("JVM_CONSTANT_UnresolvedClass", JVM_CONSTANT_UnresolvedClass); print_def("JVM_CONSTANT_ClassIndex", JVM_CONSTANT_ClassIndex); print_def("JVM_CONSTANT_UnresolvedString", JVM_CONSTANT_UnresolvedString); print_def("JVM_CONSTANT_StringIndex", JVM_CONSTANT_StringIndex); print_def("JVM_CONSTANT_UnresolvedClassInError",JVM_CONSTANT_UnresolvedClass InError); nl(); print_def("T_BOOLEAN", T_BOOLEAN); print_def("T_CHAR", T_CHAR); print_def("T_FLOAT", T_FLOAT); print_def("T_DOUBLE", T_DOUBLE); print_def("T_BYTE", T_BYTE); print_def("T_SHORT", T_SHORT); print_def("T_INT", T_INT); print_def("T_LONG", T_LONG); print_def("T_OBJECT", T_OBJECT); print_def("T_ARRAY", T_ARRAY); print_def("T_VOID", T_VOID); nl(); print_def("_thread_uninitialized", _thread_uninitialized); print_def("_thread_new", _thread_new); print_def("_thread_new_trans", _thread_new_trans); print_def("_thread_in_native", _thread_in_native); print_def("_thread_in_native_trans", _thread_in_native_trans); print_def("_thread_in_vm", _thread_in_vm); print_def("_thread_in_vm_trans", _thread_in_vm_trans); print_def("_thread_in_Java", _thread_in_Java); print_def("_thread_in_Java_trans", _thread_in_Java_trans); print_def("_thread_blocked", _thread_blocked); print_def("_thread_blocked_trans", _thread_blocked_trans); print_def("_thread_max_state", _thread_max_state); nl(); print_def("class_unparsable_by_gc", instanceKlass::unparsable_by_gc); print_def("class_allocated", instanceKlass::allocated); print_def("class_loaded", instanceKlass::loaded); print_def("class_linked", instanceKlass::linked); print_def("class_being_initialized", instanceKlass::being_initialized); print_def("class_fully_initialized", instanceKlass::fully_initialized); print_def("class_init_error", instanceKlass::initialization_error); nl(); print_def("flag_methodInterface", 1 << ConstantPoolCacheEntry::methodInterface); print_def("flag_volatileField", 1 << ConstantPoolCacheEntry::volatileField); print_def("flag_vfinalMethod", 1 << ConstantPoolCacheEntry::vfinalMethod); print_def("flag_finalField", 1 << ConstantPoolCacheEntry::finalField); nl(); VMStructs::print_vm_offsets(); nl(); print_def("VMSYMBOLS_ArithmeticException", vmSymbols::java_lang_ArithmeticException_enum); print_def("VMSYMBOLS_ArrayIndexOutOfBounds", vmSymbols::java_lang_ArrayIndexOutOfBoundsException_enum); print_def("VMSYMBOLS_ArrayStoreException", vmSymbols::java_lang_ArrayStoreException_enum); print_def("VMSYMBOLS_ClassCastException", vmSymbols::java_lang_ClassCastException_enum); print_def("VMSYMBOLS_NullPointerException", vmSymbols::java_lang_NullPointerException_enum); print_def("VMSYMBOLS_AbstractMethodError", vmSymbols::java_lang_AbstractMethodError_enum); print_def("VMSYMBOLS_IncompatibleClassChangeError", vmSymbols::java_lang_IncompatibleClassChangeError_enum); print_def("VMSYMBOLS_InternalError", vmSymbols::java_lang_InternalError_enum); return 0; } From aph at redhat.com Thu Aug 13 02:14:29 2009 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Aug 2009 10:14:29 +0100 Subject: Interpreter Offsets (was RE: ARM Interpreter) In-Reply-To: <000001ca1bf2$7b8ec470$72ac4d50$@com> References: <001601ca1b3a$d020bce0$706236a0$@com> <20090812120528.GH3241@redhat.com> <000001ca1bf2$7b8ec470$72ac4d50$@com> Message-ID: <4A83D975.7050602@redhat.com> Edward Nevill wrote: > > The way to handle this is to write a tool which generates the offsets > (called say 'mkoffsets'). You then in the build do something like > > gcc -o mkoffsets mkoffsets.cpp > ./mkoffsets > offsets.s > > And the #include "offsets.s". > > As it happens there is an interface in OpenJDK for doing exactly this sort > of thing. It is called VMStructs. I have written a version of mkoffsets.cpp > using VMStructs (see below). > > I am not sure of the best way to handle the PRODUCT vs non PRODUCT issue. > There are two possible approaches. > > 1) The first is to generate both sets of offsets in the build and use #ifdef > PRODUCT to select the correct offsets. > > Eg. > gcc -o mkoffsets mkoffsets.cpp -DPRODUCT > ./mkoffsets > product_offsets.s > gcc -o mkoffsets mkoffsets.cpp -DDEBUG > ./mkoffsets > debug_offsets.s > > Then in the asm loop do > > #ifdef PRODUCT > #include "product_offsets.s" > #else > #include "debug_offsets.s" > #endif > > 2) The 2nd is to ensure that mkoffsets is 'cleaned' for every build so that > if you switch between PRODUCT and non PRODUCT builds the offsets.s file > always gets regenerated. > > I am leaning towards the first option as the consequences of the offsets > file not being regenerated correctly are horrible. I don't quite get things, since it would be pretty trivial to do this unconditionally, but it doesn't matter much. Please amend the interpreter patch and we can get it *in*. :-) Andrew. From gbenson at redhat.com Thu Aug 13 02:42:11 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 13 Aug 2009 10:42:11 +0100 Subject: Interpreter Offsets (was RE: ARM Interpreter) In-Reply-To: <4A83D975.7050602@redhat.com> References: <001601ca1b3a$d020bce0$706236a0$@com> <20090812120528.GH3241@redhat.com> <000001ca1bf2$7b8ec470$72ac4d50$@com> <4A83D975.7050602@redhat.com> Message-ID: <20090813094211.GA3770@redhat.com> Andrew Haley wrote: > I don't quite get things, since it would be pretty trivial to do > this unconditionally, but it doesn't matter much. Please amend > the interpreter patch and we can get it *in*. :-) If there's a better way to do it then lets wait and do it that way. I'm pretty happy for the initial patch to have hardcoded constants, but I would like to see an actual patch so I can look it over. Cheers, Gary -- http://gbenson.net/ From aph at redhat.com Thu Aug 13 02:48:47 2009 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Aug 2009 10:48:47 +0100 Subject: Interpreter Offsets (was RE: ARM Interpreter) In-Reply-To: <20090813094211.GA3770@redhat.com> References: <001601ca1b3a$d020bce0$706236a0$@com> <20090812120528.GH3241@redhat.com> <000001ca1bf2$7b8ec470$72ac4d50$@com> <4A83D975.7050602@redhat.com> <20090813094211.GA3770@redhat.com> Message-ID: <4A83E17F.8060904@redhat.com> Gary Benson wrote: > Andrew Haley wrote: >> I don't quite get things, since it would be pretty trivial to do >> this unconditionally, but it doesn't matter much. Please amend >> the interpreter patch and we can get it *in*. :-) > > If there's a better way to do it then lets wait and do it that way. > I'm pretty happy for the initial patch to have hardcoded constants, > but I would like to see an actual patch so I can look it over. Sure, everything gets submitted as patches, and approved, before being committed. I just can't see any advantage to Ed being in a position where nothing is committed until the whole job is finished. No-one else works that way. Andrew. From gbenson at redhat.com Thu Aug 13 03:34:29 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 13 Aug 2009 11:34:29 +0100 Subject: Interpreter Offsets (was RE: ARM Interpreter) In-Reply-To: <4A83E17F.8060904@redhat.com> References: <001601ca1b3a$d020bce0$706236a0$@com> <20090812120528.GH3241@redhat.com> <000001ca1bf2$7b8ec470$72ac4d50$@com> <4A83D975.7050602@redhat.com> <20090813094211.GA3770@redhat.com> <4A83E17F.8060904@redhat.com> Message-ID: <20090813103429.GB3770@redhat.com> Andrew Haley wrote: > Gary Benson wrote: > > Andrew Haley wrote: > > > I don't quite get things, since it would be pretty trivial to do > > > this unconditionally, but it doesn't matter much. Please amend > > > the interpreter patch and we can get it *in*. :-) > > > > If there's a better way to do it then lets wait and do it that > > way. I'm pretty happy for the initial patch to have hardcoded > > constants, but I would like to see an actual patch so I can look > > it over. > > Sure, everything gets submitted as patches, and approved, before > being committed. I just can't see any advantage to Ed being in a > position where nothing is committed until the whole job is finished. > No-one else works that way. Like I said, I'm happy for an initial patch with hardcoded constants. ie, Ed, please make and mail a patch. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu Aug 13 05:11:04 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 13 Aug 2009 13:11:04 +0100 Subject: Make Shark free compiled methods Message-ID: <20090813121104.GC3770@redhat.com> Hi all, This commit makes Shark free the bitcode and native code for compiled methods when they are removed from the VM. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r 9420faca6468 ChangeLog --- a/ChangeLog Fri Aug 07 11:58:27 2009 +0200 +++ b/ChangeLog Thu Aug 13 08:00:49 2009 -0400 @@ -1,3 +1,22 @@ +2009-08-13 Gary Benson + + * ports/hotspot/src/share/vm/shark/sharkEntry.hpp + (SharkEntry::_function): New field. + (SharkEntry::function): New method. + (SharkEntry::set_function): Likewise. + + * ports/hotspot/src/share/vm/shark/sharkCompiler.hpp + (SharkCompiler::free_compiled_method): New method. + * ports/hotspot/src/share/vm/shark/sharkCompiler.cpp + (SharkCompiler::free_compiled_method): New method. + (SharkCompiler::compile_method): Store a pointer to + the LLVM function in the method's SharkEntry. + + * patches/hotspot/default/icedtea-shark.patch + (nmethod::flush): Add code to free Shark methods. + + * ports/hotspot/src/share/vm/includeDB_shark: Updated. + 2009-08-07 Matthias Klose * Makefile.am (ADD_ZERO_CONFIGURE_ARGS): Add configure options diff -r 9420faca6468 patches/hotspot/default/icedtea-shark.patch --- a/patches/hotspot/default/icedtea-shark.patch Fri Aug 07 11:58:27 2009 +0200 +++ b/patches/hotspot/default/icedtea-shark.patch Thu Aug 13 08:00:49 2009 -0400 @@ -374,3 +374,17 @@ address native_entry(); address interpreter_entry(); +diff -r 0d80af392e67 openjdk/hotspot/src/share/vm/code/nmethod.cpp +--- openjdk/hotspot/src/share/vm/code/nmethod.cpp Thu Jul 30 10:00:04 2009 +0100 ++++ openjdk/hotspot/src/share/vm/code/nmethod.cpp Fri Jul 31 15:39:43 2009 +0100 +@@ -1296,6 +1296,10 @@ + ec = next; + } + ++#ifdef SHARK ++ ((SharkCompiler *) compiler())->free_compiled_method(instructions_begin()); ++#endif // SHARK ++ + ((CodeBlob*)(this))->flush(); + + CodeCache::free(this); diff -r 9420faca6468 ports/hotspot/src/share/vm/includeDB_shark --- a/ports/hotspot/src/share/vm/includeDB_shark Fri Aug 07 11:58:27 2009 +0200 +++ b/ports/hotspot/src/share/vm/includeDB_shark Thu Aug 13 08:00:49 2009 -0400 @@ -57,7 +57,7 @@ llvmValue.hpp llvmHeaders.hpp llvmValue.hpp sharkType.hpp -methodOop.cpp sharkEntry.hpp +nmethod.cpp sharkCompiler.hpp shark_globals.cpp shark_globals.hpp diff -r 9420faca6468 ports/hotspot/src/share/vm/shark/sharkCompiler.cpp --- a/ports/hotspot/src/share/vm/shark/sharkCompiler.cpp Fri Aug 07 11:58:27 2009 +0200 +++ b/ports/hotspot/src/share/vm/shark/sharkCompiler.cpp Thu Aug 13 08:00:49 2009 -0400 @@ -146,6 +146,7 @@ if (!fnmatch(SharkPrintBitcodeOf, name, 0)) function->dump(); } + entry->set_function(function); // Compile to native code #ifndef PRODUCT @@ -206,6 +207,13 @@ } } +void SharkCompiler::free_compiled_method(address code) +{ + Function *function = ((SharkEntry *) code)->function(); + execution_engine()->freeMachineCodeForFunction(function); + function->eraseFromParent(); +} + const char* SharkCompiler::methodname(const ciMethod* target) { const char *klassname = target->holder()->name()->as_utf8(); diff -r 9420faca6468 ports/hotspot/src/share/vm/shark/sharkCompiler.hpp --- a/ports/hotspot/src/share/vm/shark/sharkCompiler.hpp Fri Aug 07 11:58:27 2009 +0200 +++ b/ports/hotspot/src/share/vm/shark/sharkCompiler.hpp Thu Aug 13 08:00:49 2009 -0400 @@ -45,6 +45,9 @@ // Compilation entry point for methods void compile_method(ciEnv* env, ciMethod* target, int entry_bci); + // Free compiled methods + void free_compiled_method(address code); + // LLVM interface private: llvm::Module* _module; diff -r 9420faca6468 ports/hotspot/src/share/vm/shark/sharkEntry.hpp --- a/ports/hotspot/src/share/vm/shark/sharkEntry.hpp Fri Aug 07 11:58:27 2009 +0200 +++ b/ports/hotspot/src/share/vm/shark/sharkEntry.hpp Thu Aug 13 08:00:49 2009 -0400 @@ -24,10 +24,9 @@ */ class SharkEntry : public ZeroEntry { - friend class SharkMemoryManager; - private: - address _code_limit; + address _code_limit; + llvm::Function* _function; public: address code_start() const @@ -38,9 +37,18 @@ { return _code_limit; } - protected: + llvm::Function* function() const + { + return _function; + } + + public: void set_code_limit(address code_limit) { _code_limit = code_limit; } + void set_function(llvm::Function* function) + { + _function = function; + } }; From gbenson at redhat.com Fri Aug 14 03:22:12 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 14 Aug 2009 11:22:12 +0100 Subject: Shark Refactoring Message-ID: <20090814102212.GC3331@redhat.com> Hi all, This commit moves some VM interface code from SharkFunction to SharkTopLevelBlock. It also adds a ChangeLog entry for Andrew Haley's previous commit, which was missing one. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r 172073e30a2a ChangeLog --- a/ChangeLog Thu Aug 13 16:24:01 2009 +0100 +++ b/ChangeLog Fri Aug 14 06:11:51 2009 -0400 @@ -1,3 +1,36 @@ +2009-08-14 Gary Benson + + * ports/hotspot/src/share/vm/shark/sharkFunction.hpp + (SharkFunction::CreateStoreLastJavaSP): Removed. + (SharkFunction::set_last_Java_frame): Likewise. + (SharkFunction::reset_last_Java_frame): Likewise. + (SharkFunction::CreateGetVMResult): Likewise. + (SharkFunction::pending_exception_address): Likewise. + (SharkFunction::CreateGetPendingException): Likewise. + + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp + (SharkTopLevelBlock::pending_exception_address): New method. + (SharkTopLevelBlock::get_pending_exception): Likewise. + (SharkTopLevelBlock::clear_pending_exception): Likewise. + (SharkTopLevelBlock::set_last_Java_frame): Likewise. + (SharkTopLevelBlock::reset_last_Java_frame): Likewise. + (SharkTopLevelBlock::get_vm_result): Likewise. + (SharkTopLevelBlock::call_vm): Updated. + + * ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp + (SharkTopLevelBlock::zero_check_value): Updated. + (SharkTopLevelBlock::check_bounds): Likewise. + (SharkTopLevelBlock::check_pending_exception): Likewise. + (SharkTopLevelBlock::handle_return): Likewise. + (SharkTopLevelBlock::do_new): Likewise. + (SharkTopLevelBlock::do_newarray): Likewise. + (SharkTopLevelBlock::do_anewarray): Likewise. + (SharkTopLevelBlock::do_multianewarray): Likewise. + +2009-08-13 Andrew Haley + + * configure.ac (AC_INIT): Bumped version to 1.7pre. + 2009-08-13 Gary Benson * ports/hotspot/src/share/vm/shark/sharkEntry.hpp diff -r 172073e30a2a ports/hotspot/src/share/vm/shark/sharkFunction.hpp --- a/ports/hotspot/src/share/vm/shark/sharkFunction.hpp Thu Aug 13 16:24:01 2009 +0100 +++ b/ports/hotspot/src/share/vm/shark/sharkFunction.hpp Fri Aug 14 06:11:51 2009 -0400 @@ -124,12 +124,11 @@ { return builder()->CreateStore(value, zero_stack_pointer_addr()); } - - private: llvm::LoadInst* CreateLoadZeroFramePointer(const char *name = "") { return builder()->CreateLoad(zero_frame_pointer_addr(), name); } + private: llvm::StoreInst* CreateStoreZeroFramePointer(llvm::Value* value) { return builder()->CreateStore(value, zero_frame_pointer_addr()); @@ -235,56 +234,6 @@ "displaced_header_addr"); } - // VM interface - private: - llvm::StoreInst* CreateStoreLastJavaSP(llvm::Value* value) const - { - return builder()->CreateStore( - value, - builder()->CreateAddressOfStructEntry( - thread(), JavaThread::last_Java_sp_offset(), - llvm::PointerType::getUnqual(SharkType::intptr_type()), - "last_Java_sp_addr")); - } - - public: - void set_last_Java_frame() - { - CreateStoreLastJavaSP(CreateLoadZeroFramePointer()); - } - void reset_last_Java_frame() - { - CreateStoreLastJavaSP(LLVMValue::intptr_constant(0)); - } - - public: - llvm::LoadInst* CreateGetVMResult() const - { - llvm::Value *addr = builder()->CreateAddressOfStructEntry( - thread(), JavaThread::vm_result_offset(), - llvm::PointerType::getUnqual(SharkType::jobject_type()), - "vm_result_addr"); - llvm::LoadInst *result = builder()->CreateLoad(addr, "vm_result"); - builder()->CreateStore(LLVMValue::null(), addr); - return result; - } - - public: - llvm::Value* pending_exception_address() const - { - return builder()->CreateAddressOfStructEntry( - thread(), Thread::pending_exception_offset(), - llvm::PointerType::getUnqual(SharkType::jobject_type()), - "pending_exception_addr"); - } - llvm::LoadInst* CreateGetPendingException() const - { - llvm::Value *addr = pending_exception_address(); - llvm::LoadInst *result = builder()->CreateLoad(addr, "pending_exception"); - builder()->CreateStore(LLVMValue::null(), addr); - return result; - } - // Deferred zero checks public: void add_deferred_zero_check(SharkTopLevelBlock* block, diff -r 172073e30a2a ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Thu Aug 13 16:24:01 2009 +0100 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.cpp Fri Aug 14 06:11:51 2009 -0400 @@ -334,7 +334,10 @@ else { builder()->CreateUnimplemented(__FILE__, __LINE__); } - handle_exception(function()->CreateGetPendingException(), EX_CHECK_FULL); + + Value *pending_exception = get_pending_exception(); + clear_pending_exception(); + handle_exception(pending_exception, EX_CHECK_FULL); } void SharkTopLevelBlock::check_bounds(SharkValue* array, SharkValue* index) @@ -350,6 +353,7 @@ builder()->SetInsertPoint(out_of_bounds); SharkState *saved_state = current_state()->copy(); + call_vm( builder()->throw_ArrayIndexOutOfBoundsException(), builder()->CreateIntToPtr( @@ -358,7 +362,11 @@ LLVMValue::jint_constant(__LINE__), index->jint_value(), EX_CHECK_NONE); - handle_exception(function()->CreateGetPendingException(), EX_CHECK_FULL); + + Value *pending_exception = get_pending_exception(); + clear_pending_exception(); + handle_exception(pending_exception, EX_CHECK_FULL); + set_current_state(saved_state); builder()->SetInsertPoint(in_bounds); @@ -371,16 +379,12 @@ BasicBlock *exception = function()->CreateBlock("exception"); BasicBlock *no_exception = function()->CreateBlock("no_exception"); - Value *pending_exception_addr = function()->pending_exception_address(); - Value *pending_exception = builder()->CreateLoad( - pending_exception_addr, "pending_exception"); - + Value *pending_exception = get_pending_exception(); builder()->CreateCondBr( builder()->CreateICmpEQ(pending_exception, LLVMValue::null()), no_exception, exception); builder()->SetInsertPoint(exception); - builder()->CreateStore(LLVMValue::null(), pending_exception_addr); SharkState *saved_state = current_state()->copy(); if (action & EAM_MONITOR_FUDGE) { // The top monitor is marked live, but the exception was thrown @@ -389,6 +393,7 @@ set_num_monitors(num_monitors() - 1); action ^= EAM_MONITOR_FUDGE; } + clear_pending_exception(); handle_exception(pending_exception, action); set_current_state(saved_state); @@ -630,7 +635,7 @@ } if (exception) { - builder()->CreateStore(exception, function()->pending_exception_address()); + builder()->CreateStore(exception, pending_exception_address()); } Value *result_addr = function()->CreatePopFrame(type2size[type]); @@ -1576,7 +1581,7 @@ builder()->new_instance(), LLVMValue::jint_constant(iter()->get_klass_index()), EX_CHECK_FULL); - slow_object = function()->CreateGetVMResult(); + slow_object = get_vm_result(); got_slow = builder()->GetInsertBlock(); // Push the object @@ -1608,10 +1613,8 @@ pop()->jint_value(), EX_CHECK_FULL); - push(SharkValue::create_generic( - ciArrayKlass::make(ciType::make(type)), - function()->CreateGetVMResult(), - true)); + ciArrayKlass *array_klass = ciArrayKlass::make(ciType::make(type)); + push(SharkValue::create_generic(array_klass, get_vm_result(), true)); } void SharkTopLevelBlock::do_anewarray() @@ -1631,8 +1634,7 @@ pop()->jint_value(), EX_CHECK_FULL); - push(SharkValue::create_generic( - array_klass, function()->CreateGetVMResult(), true)); + push(SharkValue::create_generic(array_klass, get_vm_result(), true)); } void SharkTopLevelBlock::do_multianewarray() @@ -1668,8 +1670,7 @@ for (int i = 0; i < ndims; i++) pop(); - push(SharkValue::create_generic( - array_klass, function()->CreateGetVMResult(), true)); + push(SharkValue::create_generic(array_klass, get_vm_result(), true)); } void SharkTopLevelBlock::acquire_method_lock() diff -r 172073e30a2a ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp --- a/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Thu Aug 13 16:24:01 2009 +0100 +++ b/ports/hotspot/src/share/vm/shark/sharkTopLevelBlock.hpp Fri Aug 14 06:11:51 2009 -0400 @@ -240,6 +240,24 @@ SharkState* saved_state, llvm::BasicBlock* continue_block); // Exceptions + private: + llvm::Value* pending_exception_address() const + { + return builder()->CreateAddressOfStructEntry( + thread(), Thread::pending_exception_offset(), + llvm::PointerType::getUnqual(SharkType::jobject_type()), + "pending_exception_addr"); + } + llvm::LoadInst* get_pending_exception() const + { + return builder()->CreateLoad( + pending_exception_address(), "pending_exception"); + } + void clear_pending_exception() const + { + builder()->CreateStore(LLVMValue::null(), pending_exception_address()); + } + public: enum ExceptionActionMask { // The actual bitmasks that things test against EAM_CHECK = 1, // whether to check for pending exceptions @@ -254,6 +272,26 @@ void check_pending_exception(int action); void handle_exception(llvm::Value* exception, int action); + // Frame anchor + private: + void set_last_Java_frame(llvm::Value* value) const + { + builder()->CreateStore( + value, + builder()->CreateAddressOfStructEntry( + thread(), JavaThread::last_Java_sp_offset(), + llvm::PointerType::getUnqual(SharkType::intptr_type()), + "last_Java_sp_addr")); + } + void set_last_Java_frame() const + { + set_last_Java_frame(function()->CreateLoadZeroFramePointer()); + } + void reset_last_Java_frame() const + { + set_last_Java_frame(LLVMValue::intptr_constant(0)); + } + // VM calls private: llvm::CallInst* call_vm(llvm::Value* callee, @@ -262,9 +300,9 @@ int exception_action) { decache_for_VM_call(); - function()->set_last_Java_frame(); + set_last_Java_frame(); llvm::CallInst *res = builder()->CreateCall(callee, args_start, args_end); - function()->reset_last_Java_frame(); + reset_last_Java_frame(); cache_after_VM_call(); if (exception_action & EAM_CHECK) { check_pending_exception(exception_action); @@ -303,6 +341,19 @@ { llvm::Value *args[] = {thread(), arg1, arg2, arg3}; return call_vm(callee, args, args + 4, exception_action); + } + + // VM call oop return handling + private: + llvm::LoadInst* get_vm_result() const + { + llvm::Value *addr = builder()->CreateAddressOfStructEntry( + thread(), JavaThread::vm_result_offset(), + llvm::PointerType::getUnqual(SharkType::jobject_type()), + "vm_result_addr"); + llvm::LoadInst *result = builder()->CreateLoad(addr, "vm_result"); + builder()->CreateStore(LLVMValue::null(), addr); + return result; } // Synchronization From gbenson at redhat.com Wed Aug 19 06:51:57 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 19 Aug 2009 14:51:57 +0100 Subject: ARM interpreter build improvements Message-ID: <20090819135157.GB3329@redhat.com> Hi all, This patch causes the ARM interpreter's bytecodes file to be generated at build time rather than having a pregenerated version in the repo. Can someone with an ARM box please test this for me? I've tested it as much as I can without one. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.gz Type: application/x-gzip Size: 45862 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090819/ab9e5bae/attachment-0001.bin From ed at camswl.com Wed Aug 19 11:03:07 2009 From: ed at camswl.com (Edward Nevill) Date: Wed, 19 Aug 2009 19:03:07 +0100 Subject: ARM interpreter build improvements Message-ID: <200908191803.n7JI37wt013899@parsley.camswl.com> Thanks for doing this Gary. I'll test it. Are you sure you wouldn't like an ARM board on your desk? Regards, Ed. >Hi all, > >This patch causes the ARM interpreter's bytecodes file to be generated >at build time rather than having a pregenerated version in the repo. >Can someone with an ARM box please test this for me? I've tested it as >much as I can without one. > >Cheers, >Gary From aph at redhat.com Wed Aug 19 07:53:29 2009 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2009 15:53:29 +0100 Subject: ARM interpreter build improvements In-Reply-To: <200908191803.n7JI37wt013899@parsley.camswl.com> References: <200908191803.n7JI37wt013899@parsley.camswl.com> Message-ID: <4A8C11E9.9050607@redhat.com> Edward Nevill wrote: > Thanks for doing this Gary. I'll test it. > > Are you sure you wouldn't like an ARM board on your desk? Beware of Geeks bearing gifts... I warn Gary now that, should you accept this, you'll be spending an eternity waiting for the thing. Beware! Bad enough that one of the Red Hat team has one of these time sinks. ;-) Andrew. From gbenson at redhat.com Wed Aug 19 07:57:56 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 19 Aug 2009 15:57:56 +0100 Subject: ARM interpreter build improvements In-Reply-To: <200908191803.n7JI37wt013899@parsley.camswl.com> References: <200908191803.n7JI37wt013899@parsley.camswl.com> Message-ID: <20090819145755.GD3329@redhat.com> Thank you. And no, I have plenty enough on my plate with PowerPC! :) Cheers, Gary Edward Nevill wrote: > Thanks for doing this Gary. I'll test it. > > Are you sure you wouldn't like an ARM board on your desk? > > Regards, > Ed. > > > Hi all, > > > > This patch causes the ARM interpreter's bytecodes file to be > > generated at build time rather than having a pregenerated version > > in the repo. Can someone with an ARM box please test this for me? > > I've tested it as much as I can without one. > > > > Cheers, > > Gary From ed at camswl.com Thu Aug 20 04:58:33 2009 From: ed at camswl.com (Edward Nevill) Date: Thu, 20 Aug 2009 12:58:33 +0100 Subject: ARM interpreter build improvements Message-ID: <200908201158.n7KBwXuS020233@parsley.camswl.com> OK. I set a build going last night. Unfortunately I had the JAVA_HOME set so the build failed. However, before it failed it had correctly created the "bytecodes_arm.s" file and this file was binary identical to the previous "bytecodes.s". cppInterpreter_asm.S had also correctly been modified to include "bytecodes_arm.s" instead of bytecodes.s. So, I am happy with this change. Please commit. Regards, Ed. >Hi all, > >This patch causes the ARM interpreter's bytecodes file to be generated >at build time rather than having a pregenerated version in the repo. >Can someone with an ARM box please test this for me? I've tested it as >much as I can without one. > >Cheers, >Gary From gbenson at redhat.com Thu Aug 20 02:32:59 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 20 Aug 2009 10:32:59 +0100 Subject: ARM interpreter build improvements In-Reply-To: <200908201158.n7KBwXuS020233@parsley.camswl.com> References: <200908201158.n7KBwXuS020233@parsley.camswl.com> Message-ID: <20090820093259.GB3332@redhat.com> Thanks, committed. Cheers, Gary Edward Nevill wrote: > OK. I set a build going last night. Unfortunately I had the > JAVA_HOME set so the build failed. > > However, before it failed it had correctly created the "bytecodes_arm.s" > file and this file was binary identical to the previous "bytecodes.s". > > cppInterpreter_asm.S had also correctly been modified to include > "bytecodes_arm.s" instead of bytecodes.s. > > So, I am happy with this change. Please commit. > > Regards, > Ed. > > >Hi all, > > > >This patch causes the ARM interpreter's bytecodes file to be generated > >at build time rather than having a pregenerated version in the repo. > >Can someone with an ARM box please test this for me? I've tested it as > >much as I can without one. > > > >Cheers, > >Gary > > -- http://gbenson.net/ From xerxes at zafena.se Thu Aug 20 03:34:52 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 20 Aug 2009 12:34:52 +0200 Subject: Shark are now up to date with llvm 2.6svn API changes up to LLVM rev 79521. In-Reply-To: <4A8C0D09.5000502@zafena.se> References: <4A8C0D09.5000502@zafena.se> Message-ID: <4A8D26CC.2080305@zafena.se> My last Icedtea6 changes enables Shark to be built using the latest llvm 2.6svn trunk. I have tested compiling Shark on X86 using LLVM rev 79521. The LLVM 2.6svn API have changed so that all Types and BasicBlocks require a LLVMContext during creation. Basically llvm::Type::*Ty have been changed to llvm::Type::get*Ty(getGlobalContext()) and BasicBlock::Create(...) have been changed to BasicBlock::Create(getGlobalContext(), ...) Cheers Xerxes From gbenson at redhat.com Thu Aug 20 05:26:26 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 20 Aug 2009 13:26:26 +0100 Subject: Shark are now up to date with llvm 2.6svn API changes up to LLVM rev 79521. In-Reply-To: <4A8D26CC.2080305@zafena.se> References: <4A8C0D09.5000502@zafena.se> <4A8D26CC.2080305@zafena.se> Message-ID: <20090820122626.GE3332@redhat.com> Thanks for doing this Xerxes. Cheers, Gary Xerxes R?nby wrote: > My last Icedtea6 changes enables Shark to be built using the latest > llvm 2.6svn trunk. > I have tested compiling Shark on X86 using LLVM rev 79521. > > The LLVM 2.6svn API have changed so that all Types and BasicBlocks > require a LLVMContext during creation. > > Basically llvm::Type::*Ty have been changed to > llvm::Type::get*Ty(getGlobalContext()) > and > BasicBlock::Create(...) have been changed to > BasicBlock::Create(getGlobalContext(), ...) > > Cheers > Xerxes -- http://gbenson.net/ From gnu_andrew at member.fsf.org Thu Aug 20 05:36:46 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 20 Aug 2009 13:36:46 +0100 Subject: ARM interpreter build improvements In-Reply-To: <200908201158.n7KBwXuS020233@parsley.camswl.com> References: <200908201158.n7KBwXuS020233@parsley.camswl.com> Message-ID: <17c6771e0908200536tfaa48b4i9b9aebf303468dab@mail.gmail.com> 2009/8/20 Edward Nevill : > OK. I set a build going last night. Unfortunately I had the JAVA_HOME > set so the build failed. > If this was with IcedTea, one wonders why we don't just set JAVA_HOME="" in our Makefile. Anyone know why we don't? > However, before it failed it had correctly created the "bytecodes_arm.s" > file and this file was binary identical to the previous "bytecodes.s". > > cppInterpreter_asm.S had also correctly been modified to include > "bytecodes_arm.s" instead of bytecodes.s. > > So, I am happy with this change. Please commit. > > Regards, > Ed. > >>Hi all, >> >>This patch causes the ARM interpreter's bytecodes file to be generated >>at build time rather than having a pregenerated version in the repo. >>Can someone with an ARM box please test this for me? ?I've tested it as >>much as I can without one. >> >>Cheers, >>Gary > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From xerxes at zafena.se Fri Aug 21 05:23:07 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Fri, 21 Aug 2009 14:23:07 +0200 Subject: [patch] ARM Shark compilation and logic fix after last months Shark refactoring. Message-ID: <4A8E91AB.1070508@zafena.se> Shark have evolved rapidly during the past months and went through several refactoring and cleaning up phases. Shark contains a workaround for the lack of atomic operations in LLVM for ARM, the workaround have unfortunately broke during the refactoring runs. This patch fixes the workaround and makes it functional again for ARM. Ok to commit to Icedtea6 trunk ? Ok to commit to Icedtea6 1.6 release branch? The changelog would be: 2009-08-21 Xerxes R?nby *ports/hotspot/src/share/vm/shark/sharkBuilder.cpp (zero_cmpxchg_int): Updated method to match current Shark and LLVM atomic calling convention. Fixes compilation error and logic for ARM. (zero_cmpxchg_ptr): Likewise. Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_shark_arm_atomic_after_refactor.patch Type: text/x-patch Size: 1175 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090821/e86504bc/attachment.bin From gbenson at redhat.com Fri Aug 21 05:37:47 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 21 Aug 2009 13:37:47 +0100 Subject: [patch] ARM Shark compilation and logic fix after last months Shark refactoring. In-Reply-To: <4A8E91AB.1070508@zafena.se> References: <4A8E91AB.1070508@zafena.se> Message-ID: <20090821123747.GB3295@redhat.com> Xerxes R?nby wrote: > Shark have evolved rapidly during the past months and went through > several refactoring and cleaning up phases. Shark contains a > workaround for the lack of atomic operations in LLVM for ARM, the > workaround have unfortunately broke during the refactoring runs. Sorry :/ > This patch fixes the workaround and makes it functional again for > ARM. > > Ok to commit to Icedtea6 trunk ? Please do. > Ok to commit to Icedtea6 1.6 release branch? I recommend we do, but it's ultimately up to aph as the release manager. Cheers, Gary -- http://gbenson.net/ From ed at camswl.com Fri Aug 21 08:56:30 2009 From: ed at camswl.com (Edward Nevill) Date: Fri, 21 Aug 2009 16:56:30 +0100 Subject: [patch] ARM Shark compilation and logic fix after last months Shark refactoring. Message-ID: <200908211556.n7LFuUiO027508@parsley.camswl.com> Looks good. I also notice to get it to build on ARM I had to add 'jit' to llvm_components in configure.ac. Regards, Ed. >Index: icedtea6/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp >=================================================================== >--- icedtea6.orig/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp 2009-08-21 14:03:25.000000000 +0200 >+++ icedtea6/ports/hotspot/src/share/vm/shark/sharkBuilder.cpp 2009-08-21 14:05:02.000000000 +0200 >@@ -385,9 +385,9 @@ > // perform these operations without delegating to a function. > > #ifdef ARM >-static jint zero_cmpxchg_int(volatile jint *ptr, jint *oldval, jint newval) >+static jint zero_cmpxchg_int(volatile jint *ptr, jint oldval, jint newval) > { >- return Atomic::cmpxchg(*newval, ptr, *oldval); >+ return Atomic::cmpxchg(newval, ptr, oldval); > } > #endif // ARM > >@@ -404,10 +404,10 @@ > > #ifdef ARM > static intptr_t zero_cmpxchg_ptr(volatile intptr_t* ptr, >- intptr_t* oldval, >- intptr_t* newval) >+ intptr_t oldval, >+ intptr_t newval) > { >- return Atomic::cmpxchg_ptr(*newval, ptr, *oldval); >+ return Atomic::cmpxchg_ptr(newval, ptr, oldval); > } > #endif // ARM From xerxes at zafena.se Fri Aug 21 05:49:31 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Fri, 21 Aug 2009 14:49:31 +0200 Subject: [patch] ARM Shark compilation and logic fix after last months Shark refactoring. - Test In-Reply-To: <4A8E91AB.1070508@zafena.se> References: <4A8E91AB.1070508@zafena.se> Message-ID: <4A8E97DB.9060501@zafena.se> Xerxes R?nby skrev: > Shark have evolved rapidly during the past months and went through > several refactoring and cleaning up phases. > Shark contains a workaround for the lack of atomic operations in LLVM > for ARM, the workaround have unfortunately broke during the refactoring > runs. > This patch fixes the workaround and makes it functional again for ARM. > > Ok to commit to Icedtea6 trunk ? > > Ok to commit to Icedtea6 1.6 release branch? > > The changelog would be: > 2009-08-21 Xerxes R?nby > > *ports/hotspot/src/share/vm/shark/sharkBuilder.cpp > (zero_cmpxchg_int): Updated method to match current Shark > and LLVM atomic calling convention. > Fixes compilation error and logic for ARM. > (zero_cmpxchg_ptr): Likewise. > > > Cheers > Xerxes > If you are curious and want to test the above fix on a non ARM system then apply the attached patch in this mail, it makes any Shark system use the atomic of zero instead of llvm, this makes it possible to test the atomic workaround on X86 and PPC systems. The reason why this works are because the workaround itself are platform independent. Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: allways_use_zeros_atomics_for_shark_for_testing.patch Type: text/x-patch Size: 1315 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090821/20f6e840/attachment.bin From xerxes at zafena.se Fri Aug 21 06:48:15 2009 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Fri, 21 Aug 2009 15:48:15 +0200 Subject: [patch] ARM Shark compilation and logic fix after last months Shark refactoring. In-Reply-To: <200908211556.n7LFuUiO027508@parsley.camswl.com> References: <200908211556.n7LFuUiO027508@parsley.camswl.com> Message-ID: <4A8EA59F.7090708@zafena.se> Edward Nevill skrev: > Looks good. > > I also notice to get it to build on ARM I had to add 'jit' to llvm_components in configure.ac. > > Regards, > Ed. > Hi Edward Thats excellent news! Could you file and email a patch for this change to configure.ac? Does the build break on your system without the change to configure.ac? Cheers Xerxes From gbenson at redhat.com Fri Aug 28 03:04:06 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 28 Aug 2009 11:04:06 +0100 Subject: Shark tweak Message-ID: <20090828100406.GA3556@redhat.com> Hi all, This small tweak allows Shark to handle cases where HotSpot's typeflow pass detects an object reference that is always NULL. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- diff -r c2ab93e26ed7 -r ba0c7c6c4896 ChangeLog --- a/ChangeLog Thu Aug 27 13:16:24 2009 -0400 +++ b/ChangeLog Fri Aug 28 11:01:49 2009 +0100 @@ -1,3 +1,8 @@ +2009-08-28 Gary Benson + + * ports/hotspot/src/share/vm/shark/sharkState.cpp + (SharkEntryState::SharkEntryState): Handle T_NULL. + 2009-08-27 Deepak Bhole * plugin/icedteanp/IcedTeaNPPlugin.cc diff -r c2ab93e26ed7 -r ba0c7c6c4896 ports/hotspot/src/share/vm/shark/sharkState.cpp --- a/ports/hotspot/src/share/vm/shark/sharkState.cpp Thu Aug 27 13:16:24 2009 -0400 +++ b/ports/hotspot/src/share/vm/shark/sharkState.cpp Fri Aug 28 11:01:49 2009 +0100 @@ -216,6 +216,10 @@ value = SharkValue::create_generic(type, NULL, i == 0 && !is_static()); break; + case ciTypeFlow::StateVector::T_NULL: + value = SharkValue::null(); + break; + case ciTypeFlow::StateVector::T_BOTTOM: break; From gbenson at redhat.com Fri Aug 28 06:37:08 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 28 Aug 2009 14:37:08 +0100 Subject: Shark OSR support Message-ID: <20090828133708.GC3556@redhat.com> Hi all, This patch adds support for on-stack replacement (OSR) to Shark. OSR allows long running methods to be JIT compiled while they are running. After a certain number of backedges, the interpreter packs the method's stack frame into a buffer and compiles a special version of the method that will unpack the buffer and start at the backedge in question. This allows methods to be compiled that wouldn't normally, and probably makes the JIT warm up faster. If you're running with -J-XX:+PrintCompilation you'll see OSR compilations in the log, marked with '%' signs: 1 java.lang.String::hashCode (60 bytes) 2 java.lang.String::indexOf (152 bytes) 3 java.lang.String::charAt (33 bytes) 4 sun.nio.cs.UTF_8$Encoder::encodeArrayLoop (490 bytes) 1% java.lang.String::indexOf @ 65 (163 bytes) 2% java.io.UnixFileSystem::normalize @ 13 (75 bytes) 3% sun.nio.cs.UTF_8$Decoder::decodeArrayLoop @ 76 (553 bytes) 5 java.lang.String::equals (91 bytes) 6 ! java.io.BufferedReader::readLine (300 bytes) 7 java.lang.String::lastIndexOf (157 bytes) 8 java.io.UnixFileSystem::normalize (75 bytes) 9 java.lang.Object:: (1 bytes) 10 sun.nio.cs.UTF_8$Decoder::decodeArrayLoop (553 bytes) 11 java.lang.String::compareTo (147 bytes) 4%s java.util.Hashtable::contains @ 31 (66 bytes) 12 java.lang.Math::min (11 bytes) ... Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.2 Type: application/x-troff-man Size: 23786 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20090828/65913bd5/attachment-0001.man