Re: [rvm-research] Using VM.SysWriteln()

Hi Pushparaj,
This is possibly because of you are calling an Uniterruptible method
from Interruptible (or vice versa). Pls check whether the respective
classes/methods are annotated accordingly with @Inline (check the
definitions of the methods involved. Higher precedence over the class
level annotations) and @Uninterruptible (check the definitions of the
classes involved).

Further information can be found from BootImageWriterOutput.txt in a
location such as
/jikesrvm/target/BaseBaseConcurrentCompressor_x86_64-linux/BootImageWriterOutput.txt

Other developers have already pointed out the exact case for your
current issue. However pls see [1] for some more information on this.

[1] http://dmakarov.github.io/work/guide/guide.html#sec-1-7

Thank you.
Regards,
Pradeeban.

On Thu, Apr 25, 2013 at 3:31 PM, Pushparaj Motamari
<[email protected]> wrote:
> Hi,
>
> I am using below class for instrumentation. The build getting failed saying,
> Uniterrupted Violation. Could you please tell
> how to avoid this?
>
> @Uninterruptible
> public class MyPrinter {
>
>      @Entrypoint
>     public static void printValue(Address o ){
>          VM.sysWriteln("MyPrinter prints the value of ESP as = "+o);
>
>     }
> }
>
> On Tue, Apr 23, 2013 at 3:14 AM, Michael Bond <[email protected]>
> wrote:
>>
>> Hi Pushparaj,
>>
>> I see two issues:
>>
>> First, it looks like recursive instrumentation is happening: printValue()
>> is calling methods that are getting instrumented with calls to printValue().
>> To restrict instrumentation to only non-VM methods at compile time:
>>
>> if
>> (method.getDeclaringClass().getDescriptor().isBootstrapClassDescriptor())
>>
>> or
>>
>> if (method.getDeclaringClass().getDescriptor().isRVMClassDescriptor())
>>
>> depending on whether or not you want to instrument the Java libraries.
>>
>> Second, printValue() needs to be @Uninterruptible since the place where
>> printValue() is getting inserted probably isn't a GC-safe point. You can add
>> the @Uninterruptible annotation to the class or method.
>>
>> That'll cause a compiler error because uninterruptible methods can only
>> call other @Uninterruptible methods, and Object.hashCode() is an
>> interruptible method. I suggest calling
>>
>> RuntimeEntrypoints.getObjectHashCode(o);
>>
>> or simply
>>
>> ObjectReference.fromObject(o).toAddress()
>>
>> depending on what exactly you want to print.
>>
>> Cheers,
>> Mike
>>
>>
>> On 04/22/2013 03:00 PM, Pushparaj Motamari wrote:
>>
>> Dear All,
>>
>> I have created a New Class for instrumenting
>>
>> public class MyPrinter {
>>
>>      @Entrypoint
>>     public static void printValue(Object o){
>>          VM.sysWriteln("MyPrinter prints the value as = ", o.hashCode());
>>     }
>> }
>>
>> and I call it using
>>            asm.emitPUSH_Reg(T0);//Checking the Object Value, by printing
>> it.
>>           genParameterRegisterLoad(asm, 1); // pass 1 parameter
>>          // asm.comment("Calling the printValueMethod");
>>
>> asm.emitCALL_Abs(Magic.getTocPointer().plus(Entrypoints.printValueMethod.getOffset()));
>>
>> and I have added it in EntryPoints.java.
>>
>> The build getting successful, but when execute I get following exception
>>
>> Exception in the primordial thread "Jikes_RBoot_Thread" while booting:
>> JikesRVM: internal error: recursive use of hardware exception registe    rs
>> (exiting)
>>   2 -- Stack --
>>   3 (0x5807a698 13214)   at [0x5807a698, 0x5b1e3ebd]
>> Lorg/jikesrvm/scheduler/RVMThread; terminate()V at line 2661
>>   4 (0x5807a6bc 13264)   at [0x5807a6bc, 0x5b344a74]
>> Lorg/jikesrvm/scheduler/RVMThread;
>> handleUncaughtException(Ljava/lang/Throwable;)V at line     4663
>>   5 (0x5807a6e0 8747)   at [0x5807a6e0, 0x5b344d0f]
>> Lorg/jikesrvm/runtime/RuntimeEntrypoints;
>> handleUncaughtException(Ljava/lang/Throwable;)V at     line 1071
>>   6 (0x5807a730 8746)   at [0x5807a730, 0x5b345b39]
>> Lorg/jikesrvm/runtime/RuntimeEntrypoints;
>> deliverException(Ljava/lang/Throwable;Lorg/jikesrv
>> m/ArchitectureSpecific$Registers;)V at line 1066
>>   7 (0x5807a774 8734)   at [0x5807a774, 0x5b0162eb]
>> Lorg/jikesrvm/runtime/RuntimeEntrypoints; deliverHardwareException(II)V at
>> line 796
>>   8 (0x5807a790 1)   at [0x5807a790, 0x5b0162eb] <hardware trap>
>>   9 (0x5807a924 10587)   at [0x5807a924, 0x5b016847]
>> Lorg/jikesrvm/classloader/Atom; toUnicodeStringInternal()Ljava/lang/String;
>>  10 (0x5807a948 10582)   at [0x5807a948, 0x5b33e6b9]
>> Lorg/jikesrvm/classloader/Atom; hashCode()I at line 887
>>  11 (0x5807a96c 3686)   at [0x5807a96c, 0x5b016388]
>> Lorg/jikesrvm/objectmodel/MyPrinter; printValue(Ljava/lang/Object;)V at line
>> 11
>>  12 (0x5807a994 10587)   at [0x5807a994, 0x5b016847]
>> Lorg/jikesrvm/classloader/Atom; toUnicodeStringInternal()Ljava/lang/String;
>> at line 277
>>  13 (0x5807a9b8 10582)   at [0x5807a9b8, 0x5b33e6b9]
>> Lorg/jikesrvm/classloader/Atom; hashCode()I at line 887
>>  14 (0x5807a9dc 3686)   at [0x5807a9dc, 0x5b016388]
>> Lorg/jikesrvm/objectmodel/MyPrinter; printValue(Ljava/lang/Object;)V at line
>> 11
>>  15 (0x5807aa04 10587)   at [0x5807aa04, 0x5b016847]
>> Lorg/jikesrvm/classloader/Atom; toUnicodeStringInternal()Ljava/lang/String;
>> at line 277
>>  16 (0x5807aa28 10582)   at [0x5807aa28, 0x5b33e6b9]
>> Lorg/jikesrvm/classloader/Atom; hashCode()I at line 887
>>  17 (0x5807aa4c 3686)   at [0x5807aa4c, 0x5b016388]
>> Lorg/jikesrvm/objectmodel/MyPrinter; printValue(Ljava/lang/Object;)V at line
>> 11
>>  18 (0x5807aa74 10587)   at [0x5807aa74, 0x5b016847]
>> Lorg/jikesrvm/classloader/Atom; toUnicodeStringInternal()Ljava/lang/String;
>> at line 277
>>  19 (0x5807aa98 10582)   at [0x5807aa98, 0x5b33e6b9]
>> Lorg/jikesrvm/classloader/Atom; hashCode()I at line 887
>>  20 (0x5807aabc 3686)   at [0x5807aabc, 0x5b016388]
>> Lorg/jikesrvm/objectmodel/MyPrinter; printValue(Ljava/lang/Object;)V at line
>> 11
>>  21 (0x5807aae4 10587)   at [0x5807aae4, 0x5b016847]
>> Lorg/jikesrvm/classloader/Atom; toUnicodeStringInternal()Ljava/lang/String;
>> at line 277
>>  22 (0x5807ab08 10582)   at [0x5807ab08, 0x5b33e6b9]
>> Lorg/jikesrvm/classloader/Atom; hashCode()I at line 887
>>
>> Please explain the reason for the above behaviour.
>>
>> Thanks & Regards
>> Pushparaj
>>
>>
>> On Mon, Apr 22, 2013 at 4:46 AM,
>> <[email protected]> wrote:
>>>
>>> Send Jikesrvm-researchers mailing list submissions to
>>>         [email protected]
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>         https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>> or, via email, send a message with subject or body 'help' to
>>>         [email protected]
>>>
>>> You can reach the person managing the list at
>>>         [email protected]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Jikesrvm-researchers digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>    1. Re: Potential issues with longjmp in bootImageRunner (Carl Ritson)
>>>    2. Doubts Regarding Jikes Stack Layout for BaseLine  Compiler
>>>       (Pushparaj Motamari)
>>>    3. Re: Doubts Regarding Jikes Stack Layout for BaseLine Compiler
>>>       (Michael Bond)
>>>    4. Trying to learn garbage collection (Thai, Richard P)
>>>    5. Error building the MMTk test harness (Dallas Treder)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Mon, 15 Apr 2013 18:22:35 +0100
>>> From: Carl Ritson <[email protected]>
>>> Subject: Re: [rvm-research] Potential issues with longjmp in
>>>         bootImageRunner
>>> To: "General discussion of Jikes RVM design, implementation, issues,
>>>         and plans" <[email protected]>
>>> Message-ID:
>>>
>>> <CAKDym5PTd0tjO2RA3G22vFpoVNRsAhu77ZUiT-keEJeKwwPOpA@mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> >>> There are a number of approaches to dealing with this:
>>> >>>  1. assume allocation will always be top-down and ignore,
>>> >>>  2. explicitly allocate thread stacks (these can be passed to
>>> >>> pthread_create),
>>> >>>  3. replace use of setjmp/longjmp with savecontext/swapcontext
>>> >>> (although these are deprecated in POSIX),
>>> >>>  4. implement a local version of longjmp without a check,
>>> >>>  5. bypass the __longjmp_chk by using glibc's internal
>>> >>> __libc_longjmp().
>>> >>>
>>> >>> Disregarding (1), (5) is the smallest change set.
>>> >>
>>> >> I'd also disregard (1). (3) and (4) don't seem attractive to me; we
>>> >> ought to rely on non-deprecated methods from the system libraries as
>>> >> much as possible.
>>> >
>>> > My opinion is (3) the best option as (2) requires the bootImageRunner
>>> > to allocate memory at a specific place in memory and manage it
>>> > (because thread heap will need to be freed).  Instead of
>>> > reimplementing setjmp/longjmp completely, bootThread already has to be
>>> > implemented in machine specific assembly to pivot the stack when
>>> > entering the VM, the existing code should hence be extended to allow
>>> > for pivoting back onto the thread stack.  In effect bootThread should
>>> > return when sysThreadTerminate is called.
>>>
>>> It has been pointed out to me that where I said (3), I meant (4).  I
>>> agree that the use of deprecated APIs is not a good option.  An
>>> possible extension to (2) is to use the explicitly allocated stacks
>>> from inside the VM and entirely bypass the allocated of thread stacks
>>> in C/C++.  Although issues regarding the primordial thread would still
>>> need to be addressed.
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Fri, 19 Apr 2013 23:48:44 +0530
>>> From: Pushparaj Motamari <[email protected]>
>>> Subject: [rvm-research] Doubts Regarding Jikes Stack Layout for
>>>         BaseLine        Compiler
>>> To: [email protected]
>>> Message-ID:
>>>
>>> <CAKO14CXwKhX-ksvBwLB__ooq9Za4kjJziDuMC56=nvNDduWTHQ@mail.gmail.com>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Dear all,
>>>
>>> I would like to know how to print the current value of a register . Like
>>> asm.comment("Text");
>>> when I try to print asm.comment(SP) ,it is just printing as ESP ..
>>> when I execute the command ..rvm -X:base:mc=true
>>>
>>> Thank You
>>>
>>> Pushparaj Motamari
>>> Instituto Superior Technico -Portugal
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Sun, 21 Apr 2013 13:00:41 -0400
>>> From: Michael Bond <[email protected]>
>>> Subject: Re: [rvm-research] Doubts Regarding Jikes Stack Layout for
>>>         BaseLine Compiler
>>> To: [email protected]
>>> Message-ID: <[email protected]>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Hi Pushparaj,
>>>
>>> asm.comment(...) performs *compile-time* printing. It can't know the
>>> run-time value of SP.
>>>
>>> To print the run-time value of SP, you can do something like the
>>> following:
>>>
>>> (1) Create an "instrumentation" method in some class (like
>>> RuntimeEntrypoints) that will get called from the compiled code:
>>>
>>>    @Entrypoint
>>>    static void myInstrumentation(Address value) {
>>>      VM.sysWriteln("Run-time value = ", value);
>>>    }
>>>
>>> (2) Add a field to Entrypoints that's a handle to the above
>>> instrumentation method.
>>>
>>> (3) Wherever you're currently modifying the baseline compiler to try to
>>> print SP, do something like this:
>>>
>>>      asm.emitPUSH_Reg(SP);
>>>      genParameterRegisterLoad(asm, 1);
>>>
>>> asm.emitCALL_Abs(Magic.getTocPointer().plus(Entrypoints.myInstrumentationMethod.getOffset()));
>>>
>>> That'll generate code that calls your instrumentation method at run
>>> time, with one parameter: the run-time value of SP.
>>>
>>> Cheers,
>>> Mike
>>>
>>> On 04/19/2013 02:18 PM, Pushparaj Motamari wrote:
>>> > Dear all,
>>> >
>>> > I would like to know how to print the current value of a register .
>>> > Like
>>> > asm.comment("Text");
>>> > when I try to print asm.comment(SP) ,it is just printing as ESP ..
>>> > when I execute the command ..rvm -X:base:mc=true
>>> >
>>> > Thank You
>>> >
>>> > Pushparaj Motamari
>>> > Instituto Superior Technico -Portugal
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Precog is a next-generation analytics platform capable of advanced
>>> > analytics on semi-structured data. The platform includes APIs for
>>> > building
>>> > apps and a phenomenal toolset for data science. Developers can use
>>> > our toolset for easy data analysis & visualization. Get a free account!
>>> > http://www2.precog.com/precogplatform/slashdotnewsletter
>>> >
>>> >
>>> > _______________________________________________
>>> > Jikesrvm-researchers mailing list
>>> > [email protected]
>>> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Sun, 21 Apr 2013 23:05:20 +0000
>>> From: "Thai, Richard P" <[email protected]>
>>> Subject: [rvm-research] Trying to learn garbage collection
>>> To: "[email protected]"
>>>         <[email protected]>
>>> Cc: csse402 <[email protected]>
>>> Message-ID:
>>>
>>> <D87E325A4A461248B6BB5AF8CC7F6282B03D3201@exchmb-tel-1.rose-hulman.edu>
>>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> I'm currently trying my hand at making a garbage collector in MMTk and
>>> I've followed the tutorial on adding a new GC
>>> (http://jikesrvm.org/Adding+a+New+GC). I've also peppered logs throughout
>>> the classes and methods of the new GC I've created, but I don't think I can
>>> really follow what's happening after running the tests.
>>>
>>> For one, I've set the properties file to utilize bitmap marking
>>> (config.mmtk.headerMarkBit=true) in the BaseBaseMarkSweepTuned.properties
>>> file and it doesn't seem to achieve anything.
>>>
>>> Another thing, the log files outputted are incredibly large. There's no
>>> discernible pattern among the methods that are called. I notice a lot of the
>>> alloc/postAlloc calls in the mutator, getPagesUsed, etc, but the file is too
>>> large for me to clearly understand it all.
>>>
>>> Would anyone have any advice as to a better way towards understanding how
>>> GC's operate in this system? At least well enough so that I can reasonably
>>> affect the files when creating my own. In addition, would anyone know how to
>>> enable bitmap marking with the built-in MarkSweep collector?
>>>
>>> Best Regards,
>>> Richard
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Sun, 21 Apr 2013 19:16:46 -0400
>>> From: Dallas Treder <[email protected]>
>>> Subject: [rvm-research] Error building the MMTk test harness
>>> To: jikesrvm-researchers <[email protected]>
>>> Message-ID:
>>>
>>> <CAFVMK+qnkbsKw_V7Aqqgi-vaqAVFzHktUxCgrEvhKVgU8Vb4JQ@mail.gmail.com>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> I am following the guides located in the
>>> http://jikesrvm.org/Care+and+Feeding section of the website, and have
>>> gotten the RVM configured and built, but when I got to the
>>> http://jikesrvm.org/The+MMTk+Test+Harness guide, and ran the ant
>>> mmtk-harness command, I got the following error:
>>>
>>> Buildfile: /home/csse/trash-man/jikesrvm/build.xml
>>>
>>> compile-vmmagic-stub:
>>>
>>> compile-options:
>>>     [mkdir] Created dir:
>>> /home/csse/trash-man/jikesrvm/target/options/classes
>>>     [javac] Compiling 10 source files to
>>> /home/csse/trash-man/jikesrvm/target/options/classes
>>>
>>> compile-mmtk:
>>>
>>> ensure-javacc:
>>>
>>> prepare-ant-tasks:
>>>     [mkdir] Created dir:
>>> /home/csse/trash-man/jikesrvm/target/tasks/classes
>>>     [javac] Compiling 16 source files to
>>> /home/csse/trash-man/jikesrvm/target/tasks/classes
>>>     [javac] Note:
>>>
>>> /home/csse/trash-man/jikesrvm/tools/ant-tasks/src/org/jikesrvm/tools/template/GenerateFromTemplate.java
>>> uses unchecked or unsafe operations.
>>>     [javac] Note: Recompile with -Xlint:unchecked for details.
>>> Trying to override old definition of task truncate
>>>
>>> ensure:
>>>      [echo] javacc does not exist or is of the wrong version.
>>> Rebuilding...
>>>
>>> prepare-ant-tasks:
>>>
>>> init-javacc-properties:
>>>
>>> fetch:
>>>     [mkdir] Created dir:
>>> /home/csse/trash-man/jikesrvm/components/javacc/4.0
>>>      [echo] Downloading (no cache available)
>>>       [get] Getting:
>>>
>>> http://java.net/projects/javacc/downloads/download/oldversions/javacc-4.0.zip
>>>       [get] To:
>>> /home/csse/trash-man/jikesrvm/components/javacc/4.0/javacc-4.0.zip
>>>       [get]
>>>
>>> http://java.net/projects/javacc/downloads/download/oldversions/javacc-4.0.zip
>>> moved
>>> to
>>>
>>> https://java.net/projects/javacc/downloads/download/oldversions/javacc-4.0.zip
>>>       [get]
>>>
>>> https://java.net/projects/javacc/downloads/download/oldversions/javacc-4.0.zip
>>> moved
>>> tohttp://java.net/downloads/javacc/oldversions/javacc-4.0.zip
>>>
>>> BUILD FAILED
>>> /home/csse/trash-man/jikesrvm/build.xml:442: The following error occurred
>>> while executing this line:
>>> /home/csse/trash-man/jikesrvm/build/components/javacc.xml:50: The
>>> following
>>> error occurred while executing this line:
>>> /home/csse/trash-man/jikesrvm/build/components/base.xml:70: The following
>>> error occurred while executing this line:
>>> /home/csse/trash-man/jikesrvm/build/components/base.xml:76: The following
>>> error occurred while executing this line:
>>> /home/csse/trash-man/jikesrvm/build/components/javacc.xml:40: The
>>> following
>>> error occurred while executing this line:
>>> /home/csse/trash-man/jikesrvm/build/components/base.xml:110: The
>>> following
>>> error occurred while executing this line:
>>> /home/csse/trash-man/jikesrvm/build/components/base.xml:118: Redirection
>>> detected from https to http. Protocol switch unsafe, not allowed.
>>>
>>> I am running this on a Ubuntu 12.10 x32 machine, running OpenJDK 1.6. If
>>> there is any more information I can provide, please let me know.
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>>
>>> ------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Precog is a next-generation analytics platform capable of advanced
>>> analytics on semi-structured data. The platform includes APIs for
>>> building
>>> apps and a phenomenal toolset for data science. Developers can use
>>> our toolset for easy data analysis & visualization. Get a free account!
>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Jikesrvm-researchers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>>
>>>
>>> End of Jikesrvm-researchers Digest, Vol 83, Issue 13
>>> ****************************************************
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>
>>
>>
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>



-- 
Pradeeban Kathiravelu.
Postgraduate Student,
Erasmus Mundus European Master in Distributed Computing,
Instituto Superior Técnico, Lisbon, Portugal.

Blog: [Llovizna] http://kkpradeeban.blogspot.com/

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr