From gbenson at redhat.com Wed Dec 5 03:34:31 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 5 Dec 2007 11:34:31 +0000 Subject: Patch: make block_comment work everywhere Message-ID: <20071205113431.GE3967@redhat.com> Hi all, I've been writing the disassembler for my PPC stuff and I noticed that while block_comment worked in some places (stubs) it did not work in others (the interpreter). Looking into it I found that there are two places where comment lists are maintained: in CodeBlobs, and in the CodeBuffers that are created from them. The assembler stores comments in its CodeBuffer, but the disassembler looks for them in the parent CodeBlob. block_comment works in some places because those places copy the comments over to the CodeBlob. It seemed a little strange to be storing in one place and looking in another, so rather than add something to copy the comments in the interpreter generator I altered the assembler to store directly into the CodeBlob, and stripped the comment code from CodeBuffer. Does the attached patch look ok? Cheers, Gary -------------- next part -------------- diff -r 9c4940256a46 openjdk/hotspot/src/share/vm/asm/assembler.cpp --- openjdk/hotspot/src/share/vm/asm/assembler.cpp +++ openjdk/hotspot/src/share/vm/asm/assembler.cpp @@ -241,9 +241,10 @@ void Label::patch_instructions(MacroAsse void AbstractAssembler::block_comment(const char* comment) { - if (sect() == CodeBuffer::SECT_INSTS) { - code_section()->outer()->block_comment(offset(), comment); - } + CodeBlob *cb = CodeCache::find_blob_unsafe(pc()); + assert(cb != NULL, "unable to locate CodeBlob"); + intptr_t offset = (intptr_t) pc() - (intptr_t) cb->instructions_begin(); + cb->add_comment(offset, comment); } diff -r 9c4940256a46 openjdk/hotspot/src/share/vm/code/codeBlob.hpp --- openjdk/hotspot/src/share/vm/code/codeBlob.hpp +++ openjdk/hotspot/src/share/vm/code/codeBlob.hpp @@ -198,14 +198,12 @@ class CodeBlob VALUE_OBJ_CLASS_SPEC { virtual void print() const PRODUCT_RETURN; virtual void print_value_on(outputStream* st) const PRODUCT_RETURN; + // Associate a comment with an offset on the stream + void add_comment(intptr_t offset, const char * comment) PRODUCT_RETURN; + // Print the comment associated with offset on stream, if there is one void print_block_comment(outputStream* stream, intptr_t offset) { _comments.print_block_comment(stream, offset); - } - - // Transfer ownership of comments to this CodeBlob - void set_comments(CodeComments& comments) { - _comments.assign(comments); } }; diff -r 9c4940256a46 openjdk/hotspot/src/share/vm/code/codeBlob.cpp --- openjdk/hotspot/src/share/vm/code/codeBlob.cpp +++ openjdk/hotspot/src/share/vm/code/codeBlob.cpp @@ -638,6 +638,10 @@ void CodeBlob::print_value_on(outputStre st->print_cr("[CodeBlob]"); } +void CodeBlob::add_comment(intptr_t offset, const char * comment) { + _comments.add_comment(offset, comment); +} + #endif void BufferBlob::verify() { diff -r 9c4940256a46 openjdk/hotspot/src/share/vm/asm/codeBuffer.cpp --- openjdk/hotspot/src/share/vm/asm/codeBuffer.cpp +++ openjdk/hotspot/src/share/vm/asm/codeBuffer.cpp @@ -617,9 +617,6 @@ void CodeBuffer::copy_code_to(CodeBlob* this->compute_final_layout(&dest); relocate_code_to(&dest); - // transfer comments from buffer to blob - dest_blob->set_comments(_comments); - // Done moving code bytes; were they the right size? assert(round_to(dest.total_code_size(), oopSize) == dest_blob->instructions_size(), "sanity"); @@ -875,11 +872,6 @@ void CodeSection::decode() { } -void CodeBuffer::block_comment(intptr_t offset, const char * comment) { - _comments.add_comment(offset, comment); -} - - class CodeComment: public CHeapObj { private: friend class CodeComments; diff -r 9c4940256a46 openjdk/hotspot/src/share/vm/asm/codeBuffer.hpp --- openjdk/hotspot/src/share/vm/asm/codeBuffer.hpp +++ openjdk/hotspot/src/share/vm/asm/codeBuffer.hpp @@ -304,7 +304,6 @@ class CodeBuffer: public StackObj { csize_t _total_size; // size in bytes of combined memory buffer OopRecorder* _oop_recorder; - CodeComments _comments; OopRecorder _default_oop_recorder; // override with initialize_oop_recorder Arena* _overflow_arena; @@ -486,7 +485,6 @@ class CodeBuffer: public StackObj { void initialize_oop_recorder(OopRecorder* r); OopRecorder* oop_recorder() const { return _oop_recorder; } - CodeComments& comments() { return _comments; } // Code generation void relocate(address at, RelocationHolder const& rspec, int format = 0) { @@ -513,8 +511,6 @@ class CodeBuffer: public StackObj { // Transform an address from the code in this code buffer to a specified code buffer address transform_address(const CodeBuffer &cb, address addr) const; - - void block_comment(intptr_t offset, const char * comment) PRODUCT_RETURN; #ifndef PRODUCT public: diff -r 9c4940256a46 openjdk/hotspot/src/share/vm/runtime/stubCodeGenerator.cpp --- openjdk/hotspot/src/share/vm/runtime/stubCodeGenerator.cpp +++ openjdk/hotspot/src/share/vm/runtime/stubCodeGenerator.cpp @@ -83,10 +83,6 @@ StubCodeGenerator::~StubCodeGenerator() #ifndef PRODUCT if (PrintStubCode) { CodeBuffer* cbuf = _masm->code(); - CodeBlob* blob = CodeCache::find_blob_unsafe(cbuf->insts()->start()); - if (blob != NULL) { - blob->set_comments(cbuf->comments()); - } bool saw_first = false; StubCodeDesc* toprint[1000]; int toprint_len = 0; From Thomas.Rodriguez at Sun.COM Wed Dec 5 17:27:30 2007 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 05 Dec 2007 17:27:30 -0800 Subject: Patch: make block_comment work everywhere In-Reply-To: <20071205113431.GE3967@redhat.com> References: <20071205113431.GE3967@redhat.com> Message-ID: <47575002.3060209@sun.com> That seems like a good idea and I think it's more straightforward in many ways than the original. I'd certainly imagined it would be useful to support comments in other situations though the original target was really for nmethods. They are being used in the stubGenerator in a few cases, and your changes would actually fix a minor issue there with the comments only being recorded if PrintStubCode is on. I'm not sure your change is completely correct though. There are a couple things to think about. First, compiled code works by emitting code into a temporary code blob with extra space and then relocating the pieces that we actually filled up into a final code blob. This means that if you move the comment collection from the CodeBuffer to the CodeBlob you still need to transfer the comments from the temporary code blob to the final nmethod. So the place where you deleted the set_comments call that transfers ownership should be changed to transfer the comments from the source blob to the dest blob. Actually you may want to move that code into relocate_code_to so that CodeBlob::expand will properly transfer the comments too. However you do it I think both expand and copy_code_to should change the ownership of the comments. The other part is that there are multiple sections in a code buffer which can contain code and the offsets are all relative to the start of the section during construction, with SECT_INSTS always being first. This means that offsets into SECT_INSTS don't change after relocation but offsets into other sections can. So if you wanted to make this completely work you might need to add some tagging to the offsets and a relocation pass to clean them up. Alternatively you could just distinguish between the cases where relocations were needed and assert that block comments don't work in those cases. All the cases where we are generating directly code into BufferBlobs should only have one section anyway. The existing code probably should have asserted when it did nothing instead of silently dropping the comments. I don't see you on the contributor agreement signatories list. Have you signed one? tom Gary Benson wrote: > Hi all, > > I've been writing the disassembler for my PPC stuff and I noticed that > while block_comment worked in some places (stubs) it did not work in > others (the interpreter). Looking into it I found that there are two > places where comment lists are maintained: in CodeBlobs, and in the > CodeBuffers that are created from them. The assembler stores comments > in its CodeBuffer, but the disassembler looks for them in the parent > CodeBlob. block_comment works in some places because those places > copy the comments over to the CodeBlob. > > It seemed a little strange to be storing in one place and looking > in another, so rather than add something to copy the comments in the > interpreter generator I altered the assembler to store directly into > the CodeBlob, and stripped the comment code from CodeBuffer. > > Does the attached patch look ok? > > Cheers, > Gary > From Paul.Hohensee at sun.com Thu Dec 6 16:09:37 2007 From: Paul.Hohensee at sun.com (Paul Hohensee) Date: Thu, 06 Dec 2007 19:09:37 -0500 Subject: Please review (L) merge 32/64 x86 assembler In-Reply-To: <47558827.7020805@sun.com> References: <47558827.7020805@sun.com> Message-ID: <47588F41.3050605@sun.com> I intend to review tis, but won't have time until next week. Is that ok? Paul steve goldman wrote: > Yet another step for: > > 5108146 Merge i486 and amd64 cpu directories > > along the way towards > 6459804 Want client (c1) compiler for x86_64 (amd64) for faster start-up > > This webrev merges the code in assembler_x86_[32|64].* into > assembler_x86.*. The webrev shows it as changes to assembler_x86_32.* > because I'm using wx and I can't use teamware to move the files. > > In addition to merging the assembler code the .cpp file was > restructured so that the instructions are in alphabetical order and in > 3 sections, generic, 32bit only, 64bit only. As a result the diffs for > that file are incomprehensible. > > As part of this there is a small step along the way to the > "ptr"ization of the code. The next webrev to appear which contains the > 64bit c1 changes goes the rest of the way. With the changes here > operations that only can do a full register sized operation don't have > a size qualifier. So movl(Register, Register) or movq(Register, > Register) are now mov(Register, Register). push/pop/bswap also don't > have a qualifier either. > > While doing this I found that some compiler (I don't remember which > but I think it was Studio) doesn't do what I expect with the macro > NULL_WORD. So you'll see (int32_t) NULL_WORD in some places (and some > old style (int) NULL being converted). I think the macro is broken but > for now I took the seemingly stupid cast route to get thru PRT. > > > Testing: > > PRT. Also this workpace is the parent of the64bit c1 workspace > which will be forthcoming soon which has also run nsk. > > webrev: > > > http://129.154.189.15/~sgoldman/webrev/asm_04Dec07_11:40:34/ > > From gbenson at redhat.com Fri Dec 7 08:21:18 2007 From: gbenson at redhat.com (Gary Benson) Date: Fri, 7 Dec 2007 16:21:18 +0000 Subject: Patch: make block_comment work everywhere In-Reply-To: <47575002.3060209@sun.com> References: <20071205113431.GE3967@redhat.com> <47575002.3060209@sun.com> Message-ID: <20071207162118.GG7644@redhat.com> Hi Tom, It's obviously a lot more complicated than I realised. I had my suspicions: the only assembler my port uses at the moment is in interpreter code and a couple of stubs (call_stub and flush_icache_stub), none of which use relocations. I should be covered by Red Hat's contributor agreement. Cheers, Gary Tom Rodriguez wrote: > That seems like a good idea and I think it's more straightforward > in many ways than the original. I'd certainly imagined it would be > useful to support comments in other situations though the original > target was really for nmethods. They are being used in the > stubGenerator in a few cases, and your changes would actually fix a > minor issue there with the comments only being recorded if > PrintStubCode is on. > > I'm not sure your change is completely correct though. There are a > couple things to think about. First, compiled code works by > emitting code into a temporary code blob with extra space and then > relocating the pieces that we actually filled up into a final code > blob. This means that if you move the comment collection from the > CodeBuffer to the CodeBlob you still need to transfer the comments > from the temporary code blob to the final nmethod. So the place > where you deleted the set_comments call that transfers ownership > should be changed to transfer the comments from the source blob to > the dest blob. Actually you may want to move that code into > relocate_code_to so that CodeBlob::expand will properly transfer the > comments too. However you do it I think both expand and > copy_code_to should change the ownership of the comments. > > The other part is that there are multiple sections in a code buffer > which can contain code and the offsets are all relative to the start > of the section during construction, with SECT_INSTS always being > first. This means that offsets into SECT_INSTS don't change after > relocation but offsets into other sections can. So if you wanted to > make this completely work you might need to add some tagging to the > offsets and a relocation pass to clean them up. Alternatively you > could just distinguish between the cases where relocations were > needed and assert that block comments don't work in those cases. > All the cases where we are generating directly code into BufferBlobs > should only have one section anyway. The existing code probably > should have asserted when it did nothing instead of silently > dropping the comments. > > I don't see you on the contributor agreement signatories list. Have > you signed one? > > tom > > Gary Benson wrote: > > Hi all, > > > > I've been writing the disassembler for my PPC stuff and I noticed > > that while block_comment worked in some places (stubs) it did not > > work in others (the interpreter). Looking into it I found that > > there are two places where comment lists are maintained: in > > CodeBlobs, and in the CodeBuffers that are created from them. The > > assembler stores comments in its CodeBuffer, but the disassembler > > looks for them in the parent CodeBlob. block_comment works in > > some places because those places copy the comments over to the > > CodeBlob. > > > > It seemed a little strange to be storing in one place and looking > > in another, so rather than add something to copy the comments in > > the interpreter generator I altered the assembler to store > > directly into the CodeBlob, and stripped the comment code from > > CodeBuffer. > > > > Does the attached patch look ok? > > > > Cheers, > > Gary From gbenson at redhat.com Thu Dec 20 04:54:58 2007 From: gbenson at redhat.com (Gary Benson) Date: Thu, 20 Dec 2007 12:54:58 +0000 Subject: Quick question Message-ID: <20071220125458.GA3880@redhat.com> Hi all, How do I allocate a block of memory that won't be considered for garbage collection but that the garbage collector will scan for oops, rewriting them if necessary? Cheers, Gary From Keith.McGuigan at Sun.COM Thu Dec 20 05:21:01 2007 From: Keith.McGuigan at Sun.COM (Keith McGuigan) Date: Thu, 20 Dec 2007 08:21:01 -0500 Subject: Quick question In-Reply-To: <20071220125458.GA3880@redhat.com> References: <20071220125458.GA3880@redhat.com> Message-ID: <476A6C3D.60102@sun.com> Gary Benson wrote: > Hi all, > > How do I allocate a block of memory that won't be considered for > garbage collection but that the garbage collector will scan for > oops, rewriting them if necessary? > > Cheers, > Gary > You can allocate out of the C-heap (see methods/macros in share/vm/memory/allocation.hpp) for the memory, and then you'll have to create an oops_do()-style method and arrange for it to be called during GC. How to call the method depends on what your intentions are for the references in the memory block, i.e., do you want them to be strong GC roots? Or not roots but just update the pointers? Since it sounds like the latter, then you can refer to the oops_do() methods in the string and symbol tables in share/vm/classfile/symbolTable.[ch]pp. The oops iterated over there aren't roots either but they just get their pointers updated. One thing to notice in that code path, though, is that the oops_do() is only called for full (major) collections since those tables are known to only refer to objects in the perm-gen. If you're referring to non-perm-gen objects you'll need your call to be called from a minor collection too. Hope that helps. -- - Keith -- - Keith From gbenson at redhat.com Thu Dec 20 09:45:48 2007 From: gbenson at redhat.com (Gary Benson) Date: Thu, 20 Dec 2007 17:45:48 +0000 Subject: Quick question In-Reply-To: <476A6C3D.60102@sun.com> References: <20071220125458.GA3880@redhat.com> <476A6C3D.60102@sun.com> Message-ID: <20071220174547.GA7488@redhat.com> Keith McGuigan wrote: > Gary Benson wrote: > > How do I allocate a block of memory that won't be considered for > > garbage collection but that the garbage collector will scan for > > oops, rewriting them if necessary? > > You can allocate out of the C-heap (see methods/macros in > share/vm/memory/allocation.hpp) for the memory, and then you'll > have to create an oops_do()-style method and arrange for it to be > called during GC. > > How to call the method depends on what your intentions are for the > references in the memory block, i.e., do you want them to be strong > GC roots? Or not roots but just update the pointers? Since it > sounds like the latter, then you can refer to the oops_do() methods > in the string and symbol tables in > share/vm/classfile/symbolTable.[ch]pp. The oops iterated over there > aren't roots either but they just get their pointers updated. One > thing to notice in that code path, though, is that the oops_do() is > only called for full (major) collections since those tables are > known to only refer to objects in the perm-gen. If you're referring > to non-perm-gen objects you'll need your call to be called from a > minor collection too. > > Hope that helps. Thank you. Merry Christmas! Cheers, Gary From pratik.patel at einfochips.com Thu Dec 27 08:02:36 2007 From: pratik.patel at einfochips.com (Pratik Patel) Date: Thu, 27 Dec 2007 21:32:36 +0530 Subject: Unable to Compile HotSpot Message-ID: <20071227155530.4A29B52ADD6@mail.openjdk.java.net> Hi, I am compiling hotspot JVM for the first time on Linux. I have JDK-1.5.0 BootStrap, JDK-1.6.0 Source Class Library. I have installed bootstrap successfully. I got following error. Please let me know solution of this error, if any one has encountered the same problem. =============================================== Compiling /home/pratik/hotspot/src/share/vm/code/vtableStubs.cpp Compiling /home/pratik/hotspot/src/cpu/x86/vm/vtableStubs_x86_32.cpp Compiling /home/pratik/hotspot/src/os/linux/vm/vtune_linux.cpp Compiling /home/pratik/hotspot/src/share/vm/utilities/workgroup.cpp Compiling /home/pratik/hotspot/src/share/vm/utilities/xmlstream.cpp Compiling /home/pratik/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp Compiling /home/pratik/hotspot/src/share/vm/opto/idealGraphPrinter.cpp Assembling /home/pratik/hotspot/src/os_cpu/linux_x86/vm/linux_x86_32.s Compiling /home/pratik/hotspot/src/share/vm/runtime/vm_version.cpp rm -f mapfile cat /home/pratik/hotspot/build/linux/makefiles/mapfile-vers-product > mapfile rm -f mapfile_reorder cat mapfile > mapfile_reorder Linking vm... /usr/bin/chcon: failed to change context of libjvm.so to root:object_r:textrel_shlib_t: Invalid argument ERROR: Cannot chcon libjvm.so make[4]: *** [libjvm.so] Error 1 make[4]: Leaving directory `/home/pratik/hotspot/build/linux/linux_i486_compiler2/product' make[3]: *** [the_vm] Error 2 make[3]: Leaving directory `/home/pratik/hotspot/build/linux/linux_i486_compiler2/product' make[2]: *** [product] Error 2 make[2]: Leaving directory `/home/pratik/hotspot/build/linux' make[1]: *** [generic_build2] Error 2 make[1]: Leaving directory `/home/pratik/hotspot/make' make: *** [product] Error 2 =============================================== Thanks in advance for reply. Regards, Pratik Patel -- eInfochips Business Disclaimer: This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose,distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated.Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc(?eInfochips?) unless sent with that express intent and with due authority of eInfochips.EInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20071227/f4108c57/attachment.html From Kelly.Ohair at Sun.COM Sat Dec 29 10:28:34 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 29 Dec 2007 10:28:34 -0800 Subject: Unable to Compile HotSpot In-Reply-To: <20071227155530.4A29B52ADD6@mail.openjdk.java.net> References: <20071227155530.4A29B52ADD6@mail.openjdk.java.net> Message-ID: <477691D2.50009@sun.com> Every Linux system seems to be different with regards to chcon. Look into changing the file hotspot/build/linux/makefiles/vm.make to remove the use of chcon. -kto Pratik Patel wrote: > Hi, > > > > I am compiling hotspot JVM for the first time on Linux. I have JDK-1.5.0 > BootStrap, JDK-1.6.0 Source Class Library. I have installed bootstrap > successfully. > > I got following error. Please let me know solution of this error, if any > one has encountered the same problem. > > > > =============================================== > > Compiling /home/pratik/hotspot/src/share/vm/code/vtableStubs.cpp > > Compiling /home/pratik/hotspot/src/cpu/x86/vm/vtableStubs_x86_32.cpp > > Compiling /home/pratik/hotspot/src/os/linux/vm/vtune_linux.cpp > > Compiling /home/pratik/hotspot/src/share/vm/utilities/workgroup.cpp > > Compiling /home/pratik/hotspot/src/share/vm/utilities/xmlstream.cpp > > Compiling /home/pratik/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp > > Compiling /home/pratik/hotspot/src/share/vm/opto/idealGraphPrinter.cpp > > Assembling /home/pratik/hotspot/src/os_cpu/linux_x86/vm/linux_x86_32.s > > Compiling /home/pratik/hotspot/src/share/vm/runtime/vm_version.cpp > > rm -f mapfile > > cat /home/pratik/hotspot/build/linux/makefiles/mapfile-vers-product > > mapfile > > rm -f mapfile_reorder > > cat mapfile > mapfile_reorder > > Linking vm... > > /usr/bin/chcon: failed to change context of libjvm.so to > root:object_r:textrel_shlib_t: Invalid argument > > ERROR: Cannot chcon libjvm.so > > make[4]: *** [libjvm.so] Error 1 > > make[4]: Leaving directory > `/home/pratik/hotspot/build/linux/linux_i486_compiler2/product' > > make[3]: *** [the_vm] Error 2 > > make[3]: Leaving directory > `/home/pratik/hotspot/build/linux/linux_i486_compiler2/product' > > make[2]: *** [product] Error 2 > > make[2]: Leaving directory `/home/pratik/hotspot/build/linux' > > make[1]: *** [generic_build2] Error 2 > > make[1]: Leaving directory `/home/pratik/hotspot/make' > > make: *** [product] Error 2 > > =============================================== > > > > Thanks in advance for reply. > > Regards, > > Pratik Patel > > > > > -- > eInfochips Business Disclaimer: > > This message may contain confidential, proprietary or legally Privileged > information. In case you are not the original intended Recipient of the > message, you must not, directly or indirectly, use, Disclose,distribute, > print, or copy any part of this message and you are requested to delete > it and inform the sender. Any views expressed in this message are those > of the individual sender unless otherwise stated.Nothing contained in > this message shall be construed as an offer or acceptance of any offer > by eInfochips Limited and/or eInfochips Inc(?eInfochips?) unless sent > with that express intent and with due authority of eInfochips.EInfochips > has taken enough precautions to prevent the spread of viruses. However > the company accepts no liability for any damage caused by any virus > transmitted by this email. > >