From rgougol at email.sjsu.edu  Sat Dec  1 06:53:49 2007
From: rgougol at email.sjsu.edu (rgougol at email.sjsu.edu)
Date: Sat,  1 Dec 2007 06:53:49 -0800
Subject: Defect 6612732
Message-ID: <1196520829.4751757d1a756@web-mail.sjsu.edu>

Very nice. I am more interested in defect 6478991. I can not though access the
attachment class which is supposed to illustrate the problem. How to get to the
attached files in the database? 

Sincerely,

Rouhollah Gougol

Quoting Tom Rodriguez <Thomas.Rodriguez at Sun.COM>:

> The jdk starter bug list doesn't appear to be updated very frequently 
> and we don't appear to provide access to keywords which is unfortunate. 
>   Check out 6415680 or 6478991.  6415680 is basically the windows 
> version of 4454115 which is linked in the bug report and provides more 
> detail.
> 
> tom
> 
> rgougol at email.sjsu.edu wrote:
> > It is nice to get guidelines. How can I look up the tagged defects. The
> search 
> > engine does not find them... please give me more direction or their
> numbers.
> > 
> > Sincerely,
> > 
> > Nima Rouhollah Gougol
> > 
> > Quoting Tom Rodriguez <Thomas.Rodriguez at Sun.COM>:
> > 
> >> I thought that bug was closed.  The test is actually invalid since it 
> >> isn't using the strict modifier so extra precision in the expression is 
> >> allowed.  See 6579973.  Anyway, I've closed that bug so don't bother 
> >> looking at it.  I tagged a couple bugs in compiler1 as openjdk-starter 
> >> but I don't see very many in compiler2 that would be easy to pickup and 
> >> fix quickly.
> >>
> >> tom
> >>
> >> rgougol at email.sjsu.edu wrote:
> >>> Thanks for all the feadbacks in advance. So I switched to this defect, 
> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6612732 . The problem
> is
> >>> basically that C1 computes Double.MAX_VALUE * Double.MAX_VALUE == 
> >>> Double.POSITIVE_INFINITY incorrectably false which should be true. The
> >> defect 
> >>> is reproduced by invoking java -Xcomp -XX:UseSSE=1 . However this defect
> is
> >> not 
> >>> reproduced in mixed mode even if the problematic method contains a large
> >> loop 
> >>> and does get compiled?! Does it mean this defeat is extra complicated
> too?
> >> I 
> >>> thought I should catch the defect starting from the function 
> >>> LIRGenerator::do_ArithmeticOp_FPU(ArithmeticOp*) . However this function
> is
> >>> catched by GDB after the compilation of the problematic method?! Would
> it
> >> be 
> >>> the right method to start tracing from?
> >>>
> >>> Sincerely,
> >>>
> >>> Nima Rouhollah Gougol
> > 
> > 
> 




From wimmer at ssw.jku.at  Sat Dec  1 07:03:29 2007
From: wimmer at ssw.jku.at (Christian Wimmer)
Date: Sat, 1 Dec 2007 16:03:29 +0100
Subject: Defect 6612732
In-Reply-To: <1196520829.4751757d1a756@web-mail.sjsu.edu>
References: <1196520829.4751757d1a756@web-mail.sjsu.edu>
Message-ID: <000101c8342b$570cbdb0$26140a0a@Bianca>

Hi

> Very nice. I am more interested in defect 6478991. I can not 
> though access the
> attachment class which is supposed to illustrate the problem. 
> How to get to the
> attached files in the database? 

I added the test case as a comment to the bug.

Christian



From rgougol at email.sjsu.edu  Sat Dec  1 22:29:18 2007
From: rgougol at email.sjsu.edu (rgougol at email.sjsu.edu)
Date: Sat,  1 Dec 2007 22:29:18 -0800
Subject: Defect 6612732
Message-ID: <1196576958.475250be26599@web-mail.sjsu.edu>

Thanks for the correspondence. The sample class does reproduce the defect with
JDK 1.6 but not with JDK 1.7.0 (build 1.7.0-ea-b22) and the sample works
fine. So, have you guys already fixed this defect? Please let me know what I can
do for the defect? Should work on JDK 1.6 ? 

There is still  the comment of NEEDS_CLEANUP. Is that the target for the defect?
I can not really understand the discussion though. Could clarify and rationalize
this statement a little bit more, "Anything across which we can not hoist the
debug information for a NullCheck instruction must clear it."  

Sincerely

R. Gougol



Quoting Christian Wimmer <wimmer at ssw.jku.at>:

> Hi
> 
> > Very nice. I am more interested in defect 6478991. I can not 
> > though access the
> > attachment class which is supposed to illustrate the problem. 
> > How to get to the
> > attached files in the database? 
> 
> I added the test case as a comment to the bug.
> 
> Christian
> 




From wimmer at ssw.jku.at  Mon Dec  3 10:15:48 2007
From: wimmer at ssw.jku.at (Christian Wimmer)
Date: Mon, 3 Dec 2007 19:15:48 +0100
Subject: Defect 6612732
In-Reply-To: <1196576958.475250be26599@web-mail.sjsu.edu>
References: <1196576958.475250be26599@web-mail.sjsu.edu>
Message-ID: <006a01c835d8$87f13880$26140a0a@Bianca>

Hi

> Thanks for the correspondence. The sample class does 
> reproduce the defect with
> JDK 1.6 but not with JDK 1.7.0 (build 1.7.0-ea-b22) and the 
> sample works
> fine. So, have you guys already fixed this defect? 

No, the bug is still there. The inlining policy changed a bit, so that the
relevant method is no longer inlined with the command line specified in the
bug report.

> Please let me know what I can
> do for the defect? Should work on JDK 1.6 ? 

Use the following command line flags:

  -Xcomp -XX:CompileOnly=NullCheckTest.test,NullCheckTest$A.inlined
-XX:+PrintCompilation -XX:+PrintInlining


You should get this (or a similar) output:

CompileOnly: compileonly *NullCheckTest*.test
VM option 'CompileOnly=NullCheckTest.test,NullCheckTest$A.inlined'
VM option '+PrintCompilation'
VM option '+PrintInlining'
CompileOnly: compileonly *NullCheckTest$A*.inlined
  1   b   at.ssw.test.NullCheckTest::test (11 bytes)
           @ 2   at.ssw.test.NullCheckTest$A::inlined (6 bytes)
FAILURE: ClassCastException


Christian



From rgougol at email.sjsu.edu  Mon Dec  3 11:41:38 2007
From: rgougol at email.sjsu.edu (rgougol at email.sjsu.edu)
Date: Mon,  3 Dec 2007 11:41:38 -0800
Subject: scheduling of compilation task
In-Reply-To: <13adfe140711270946p7d923ff4gd2ae586e173f29e7@mail.gmail.com>
References: <13adfe140711260712x24127763kab2f4ef1e6a10cdc@mail.gmail.com>
	<1196116529.474b4a313e8f0@web-mail.sjsu.edu>
	<13adfe140711270946p7d923ff4gd2ae586e173f29e7@mail.gmail.com>
Message-ID: <1196710898.47545bf253848@web-mail.sjsu.edu>

Interesting, It seems we are working in similar fields. But I am starter so I cc
this message to the group maybe the main developer help you more if you have not
asked them yet. Here are the resouces I have. I do not want to publish my own
draft yet since it is not complete but I will be happy to answer your questions
if I can.

http://libra.msra.cn/paperdetail.aspx?id=1904842&query=operating+system
Compilation Scheduling for the Java Virtual Machine(2005)  
  Robert Chun  Azeem S. Jiva   
 Conference: Int. Conf. on Programming Languages and Compilers - PLC 

http://java.sun.com/javase/technologies/hotspot/index.jsp

The Java HotSpot Performance Engine Architecture. White paper available at
http://java.sun.com/products/hotspot/whitepaper.html, June 2007.

Tim Lindholm, Frank Yellin. The JavaTM Virtual Machine Specification, Second
Edition

Dever, S., Goldman, S. & Russel, K. New Compiler Optimizations in Java
HotSpot Virtual Machine. Sun Microsystem, Inc. 2006 JavaOne conference. TS-
3412.


Tom Rodriguez, Ken Russell. Client Compiler for the Java HotSpot ?Virtual
Machine Technology and Application. Sun Microsyst ms,Inc.



Quoting Chmielewski Andreas <dipl.andreas at googlemail.com>:

> Hello,
> 
> thanks for your answer. Do u know any source i can read something about
> hotspot? I know that the code-sources are public but its still a pain to
> read and especially to understand the technique they are using.

> 
> In particular my intention to write thru that mailing list was to find out
> if there are any papers about the scheduling technique of hotspot.Maybe my
> question is not very clear so i wanna describe u that one:
> 
> Lets guess we just have a fixed threshold decides when we do compile a
> method. We start our application, after some time we get many compilation
> tasks and now we try to compile them all at the same moment. As u can
> imagine the application slows down (especially if the code generator doesn?t
> work very fast). That problem gets reinforced by using a less powerful pc
> (especially on a small embbeded device). If we are running with a
> Round-Robin-Scheduler that kind of problem won?t have an important effect
> cause every thread gets sufficient time. But what do we do if we run on a
> fixed-priority-preemptive-Scheduler. Maybe we even don?t get enough time if
> the compilation thread runs on very low priority (1). More worse it is if we
> work on a higher priority (like 10). We may slow down the application
> dramatically if we have many compilation tasks. Both strategies are bad :)
> 
> I didn?t asked here for any solutions ( i know i need to find them :) ) for
> that kind of problem but I have asked for where i can get any information
> about this.
> 
> If u like to know what kind of solution i have found right now and how it
> performs, fell free to ask me :) I just need also different solutions for
> the draft of my diploma thesis.
> 
> kindly regards
> 
> Andreas
> 
> 
> 
> 2007/11/26, rgougol at email.sjsu.edu <rgougol at email.sjsu.edu >:
> >
> >
> > As far as I am concerned, Java HotSpot uses fixed thresholds for
> > triggering the
> > JIT profiling and compiling. HotSpot queues the compilation tasks in a
> > first-in-first-served order. HotSpot adds the number of times a method is
> > called
> > to the number of times code blocks inside the method looped and the
> > compare the
> > sum to the interpretation limit. The thresholds are though different
> > for  the
> > variant modes (client server), tiers (in multi-layer compilation is
> > enabled, and
> > platforms. I guess you may want to take a look at the following source
> > files and
> > lines of code:
> >
> > hotspot/src/cpu/x86/vm/cppInterpreter_x86.cpp /home/user/sizefactor-@@
> > -540,15
> > +540,18 @@
> >    __ andl(rax, InvocationCounter::count_mask_value);  // mask out the
> > status bits
> >
> >    __ movl(invocation_counter, rcx);                    // save invocation
> > count
> >    __ addl(rcx, rax);                           // add both counters
> >
> >    // profile_method is non-null only for interpreted method so
> >    // profile_method != NULL == !native_call
> >    // BytecodeInterpreter only calls for native so code is elided.
> >
> >   __ cmp32(rcx,
> >
> > ExternalAddress((address)&InvocationCounter::InterpreterInvocationLimit));
> >   __ jcc(Assembler::aboveEqual, *overflow);
> >
> >
> > hotspot/src/cpu/x86/vm/templateInterpreter_x86_32.cpp
> > 334,7
> >    __ andl(rax, InvocationCounter::count_mask_value);  // mask out the
> > status bits
> >
> >    __ movl(invocation_counter, rcx);                    // save invocation
> > count
> >   __ addl(rcx, rax);                            // add both counters
> >
> >    // profile_method is non-null only for interpreted method so
> >    // profile_method != NULL == !native_call
> > @@ -342,18 +342,24 @@
> >
> >    if (ProfileInterpreter && profile_method != NULL) {
> >      // Test to see if we should create a method data oop
> >     __ cmp32(rcx,
> >
> > ExternalAddress((address)&InvocationCounter::InterpreterProfileLimit));
> >     __ jcc(Assembler::less, *profile_method_continue);
> >
> >      // if no method data exists, go to profile_method
> >      __ test_method_data_pointer(rax, *profile_method);
> >    }
> >
> >   __ cmp32(rcx,
> >
> > ExternalAddress((address)&InvocationCounter::InterpreterInvocationLimit));
> >    __ jcc(Assembler::aboveEqual, *overflow);
> > }
> >
> >
> >
> > openjdk/hotspot/src/cpu/x86/vm/templateTable_x86_32.cpp
> > /home/user/sizefactor-
> > @@ -1543,14 +1543,15 @@
> >      __ increment(rax, InvocationCounter::count_increment); // increment
> > counter
> >      __ movl(Address(rcx, be_offset), rax);        // store counter
> >
> >     __ movl(rax, Address(rcx, inv_offset));    // load invocation counter
> >     __ andl(rax, InvocationCounter::count_mask_value);     // and the
> > status bits
> >     __ addl(rax, Address(rcx, be_offset));        // add both counters
> >      if (ProfileInterpreter) {
> >        // Test to see if we should create a method data oop
> >       __ cmp32(rax,
> >                 ExternalAddress((address)
> > &InvocationCounter::InterpreterProfileLimit));
> >        __ jcc(Assembler::less, dispatch);
> >
> >        // if no method data exists, go to profile method
> > @@ -1558,8 +1559,9 @@
> >
> >        if (UseOnStackReplacement) {
> >          // check for overflow against rbx, which is the MDO taken count
> >         __ cmp32(rbx,
> >                  ExternalAddress((address)
> >
> >
> > /openjdk/hotspot/src/share/vm/runtime/globals.hpp       2007-10-12 03:46:
> > 16.000000000
> > -0400
> > +++ /home/user/sizefactor-openjdk/hotspot/src/share/vm/runtime/globals.hpp
> >
> > 2007-10-31 02:02:28.000000000 -0400
> > @@ -2946,6 +2946,9 @@
> >    product_pd(intx,
> > CompileThreshold,                                        \
> >            "number of interpreted method invocations before
> > (re-)compiling") \
> >
> > \
> >
> > src/share/vm/compiler/compileBroker.cpp
> >
> > @@ -430,8 +430,6 @@
> > void CompileQueue::add(CompileTask* task) {
> >    assert(lock()->owned_by_self(), "must own lock");
> >
> > task->set_next(NULL);
> >
> >    if (_last == NULL) {
> >      // The compile queue is empty.
> >      assert(_first == NULL, "queue is empty");
> > @@ -440,8 +438,31 @@
> >    } else {
> >      // Append the task to the queue.
> >      assert(_last->next() == NULL, "not last");
> >     _last->set_next(task);
> >     _last = task;
> >
> >
> >
> > Quoting Chmielewski Andreas <dipl.andreas at googlemail.com >:
> >
> > > Hello,
> > >
> > > i am a student currently working on a diploma thesis for which i develop
> > a
> > > simple JitProfiler/JitCompiler (PPC architecture) for a realtime
> > Java-VM.
> > > That VM is using a fixed priority preemptive Scheduler. To ensure the
> > > realtime capability, the compilation task is running on the lowest
> > priority.
> > >
> > >
> > >  As I have seen in some tests the compilation task won?t get enough cpu
> > time
> > > for his work cause its running on lowest priority. So a different more
> > > aggressive strategy was needed. Therefore i have implemented a self
> > > contained Scheduler for the jit compilation task. This ensures that the
> > > compilation task will get at least a little bit of time for his work by
> > > increasing the priority to 10 (still below realtime priorities). As far
> > as
> > > it works fine now. But i got / still have some small problems ....
> > >
> > >
> > >  So in particular i would like to ask here if there is somebody who can
> > > provide me with information about the scheduling of Hotspot or different
> > > compilers.
> > >
> > >
> > >  If there are any questions feel free to write an email to me :) I would
> > be
> > > very thankful getting useful information :)
> > >
> > >
> > >  Regards
> > >
> > >
> > >  Andreas
> > >
> >
> >
> >
> 




From John.Rose at Sun.COM  Mon Dec 10 20:06:30 2007
From: John.Rose at Sun.COM (John Rose)
Date: Mon, 10 Dec 2007 20:06:30 -0800
Subject: for review (S): 6610906: inexplicable IncompatibleClassChangeError
References: <C99961AF-962C-45C6-A93B-53D7794A131A@Sun.COM>
Message-ID: <7680C93F-F6D9-4D2E-94CC-81BE54B7D87F@sun.com>

It looks like we've switched now away from the internal aliases.

Here's a code review I recently sent internally, which really should  
have been external.

Vladimir, Tom, Steve:  Thanks for the reviews; I'll put you in the  
changeset comment as soon as I learn your OpenJDK names.

Non-Sun people:  Welcome to the party!

-- John

P.S.  My first try at sending this went (as spam) to compiler- 
dev at openjdk.java.net,
which is the list for javac developers.  Oops.

Begin forwarded message:

From: John Rose <John.Rose at Sun.COM>
Date: December 5, 2007 6:46:46 PM PST
To: hs-compiler Compiler <hs-compiler at sun.com>
Cc: Mark Reinhold <mr at sun.com>
Subject: for review (S): 6610906: inexplicable  
IncompatibleClassChangeError

http://homepage.mac.com/rose00/work/webrev/6610906/

-- John

P.S.  This is my first stumble toward a mercurial-based putback....

To get a more "open" feel for this review, I put this webrev up on an  
external site.
The repo. is on my MacBook.  I think only the Bugster interactions  
have required SWAN access.

However, I'm sending the request to our internal mail alias, not the  
openjdk group alias.
Also, this putback can't go anywhere yet, since the parent repo.  
(hotspot-comp) is still the experimental one.
(My repo. is freshly cloned from http://hg.openjdk.java.net/jdk7/jdk7/ 
hotspot .)

I generated the webrev using this command:
   /java/devtools/share/bin/webrev  -ON -i 6610906-comments.html

The contents of the "author comments" file looks like this:

For putback to <a href="http://hg.openjdk.java.net/jdk7/hotspot-comp- 
gate/hotspot">http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/ 
hotspot</a>
<br><a href="http://bugs.sun.com/bugdatabase/view_bug.do? 
bug_id=6610906">6610906</a>: inexplicable IncompatibleClassChangeError
<br>Summary: dependency check must treat polymorphic interfaces  
consistently
<br>Reviewed-by: ??

I'll strip the formatting (which webrev should have put in for me)  
and use it as a changeset comment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20071210/fe5d2808/attachment.html 

From rgougol at email.sjsu.edu  Thu Dec 20 14:32:38 2007
From: rgougol at email.sjsu.edu (rgougol at email.sjsu.edu)
Date: Thu, 20 Dec 2007 14:32:38 -0800
Subject: My Patch for Defect 6478991
In-Reply-To: <1196520829.4751757d1a756@web-mail.sjsu.edu>
References: <1196520829.4751757d1a756@web-mail.sjsu.edu>
Message-ID: <1198189958.476aed86b2ade@web-mail.sjsu.edu>

Hello everybody and thanks for the feedbacks so far,

Here comes my suggested patch for the defect of NullCheck Elimination. Basically
it sets a flag if a type check operation is iterated. This flag prevents the 
optimizations of folding the NullChecks and let the elimination of the latter
NullCheck exception instead of the former. The flag is unset when the last
explicit exception is set. I will be very thankful if I get any feedback? Shall
I extend the patch to all the trap instruction besides type checks? Can also
somebody explain me what is the purpose of folding null check exception and why
should the former null check be eliminated instead of the latter? 

--- openjdk/hotspot/src/share/vm/c1/c1_Optimizer.cpp	2007-10-12
00:46:03.000000000 -0700
+++ nullcheck-openjdk/hotspot/src/share/vm/c1/c1_Optimizer.cpp	2007-12-19
14:22:58.000000000 -0800
@@ -490,6 +490,9 @@
   // Returns true if caused a change in the block's state.
   bool      merge_state_for(BlockBegin* block,
                             ValueSet*   incoming_state);
+  Instruction *  _prior_type_check;
+  Instruction *  prior_type_check() const { return _prior_type_check; }
+  void set_prior_type_check(Instruction * instr) { _prior_type_check = instr; } 
 
  public:
   // constructor
@@ -498,7 +501,8 @@
     , _set(new ValueSet())
     , _last_explicit_null_check(NULL)
     , _block_states(BlockBegin::number_of_blocks(), NULL)
-    , _work_list(new BlockList()) {
+    , _work_list(new BlockList())
+    , _prior_type_check (NULL)  {
     _visitable_instructions = new ValueSet();
     _visitor.set_eliminator(this);
   }
@@ -715,6 +719,9 @@
     // visiting instructions which are references in other blocks or
     // visiting instructions more than once.
     mark_visitable(instr);
+    if (instr->as_TypeCheck() != NULL ) {
+	set_prior_type_check(instr);
+    }
     if (instr->is_root() || instr->can_trap() || (instr->as_NullCheck() != NULL)) {
       mark_visited(instr);
       instr->input_values_do(&NullCheckEliminator::do_value);
@@ -769,13 +776,14 @@
   Value obj = x->obj();
   if (set_contains(obj)) {
     // Value is non-null => update AccessField
-    if (last_explicit_null_check_obj() == obj && !x->needs_patching()) {
+    if (last_explicit_null_check_obj() == obj && !x->needs_patching() && !
prior_type_check()) {
     } else {
       x->set_explicit_null_check(NULL);
       x->set_needs_null_check(false);
@@ -800,7 +808,7 @@
   Value array = x->array();
   if (set_contains(array)) {
     // Value is non-null => update AccessArray
-    if (last_explicit_null_check_obj() == array) {
+    if (last_explicit_null_check_obj() == array && ! prior_type_check()) {
       x->set_explicit_null_check(consume_last_explicit_null_check());
       x->set_needs_null_check(true);
       if (PrintNullCheckElimination) {
@@ -831,7 +839,7 @@
   Value array = x->array();
   if (set_contains(array)) {
     // Value is non-null => update AccessArray
-    if (last_explicit_null_check_obj() == array) {
+    if (last_explicit_null_check_obj() == array && ! prior_type_check()) {
       x->set_explicit_null_check(consume_last_explicit_null_check());
       x->set_needs_null_check(true);
       if (PrintNullCheckElimination) {
@@ -898,6 +906,7 @@
     if (PrintNullCheckElimination) {
       tty->print_cr("NullCheck %d of value %d proves value to be non-null",
x->id(), obj->id());
     }
+    set_prior_type_check(NULL);
   }
 }
 

Sincerely,

Rouhollah Gougol





From wimmer at ssw.jku.at  Fri Dec 21 07:48:18 2007
From: wimmer at ssw.jku.at (Christian Wimmer)
Date: Fri, 21 Dec 2007 16:48:18 +0100
Subject: My Patch for Defect 6478991
In-Reply-To: <1198189958.476aed86b2ade@web-mail.sjsu.edu>
References: <1196520829.4751757d1a756@web-mail.sjsu.edu>
	<1198189958.476aed86b2ade@web-mail.sjsu.edu>
Message-ID: <01b901c843e8$e83c78d0$d8914e8c@Bianca>

Hi

> Here comes my suggested patch for the defect of NullCheck 
> Elimination. Basically
> it sets a flag if a type check operation is iterated. This 
> flag prevents the 
> optimizations of folding the NullChecks and let the 
> elimination of the latter
> NullCheck exception instead of the former. 

You patch looks like a quick hack to circumvent this special problem, but
not like a general solution to the problem. 

I also think that your approach ist not suitable: why introduce a new flag
when there is already one, namely "last_explicit_null_check". You should
better call the method "clear_last_explicit_null_check" at all places where
it is necessary.

A technical remark is that you should not need to call the method
as_TypeCheck. The visitor design pattern of the null check eliminator
provides a distinct method for each instruction type.

Another important aspect that you should consider when creating a patch is
the impact on the performance: Does your change has a significant impact on
a benchmark?

I am not a Sun employee, so I have no influence if your patch will be
accepted or not. I just don't like bugfixes that introduce new flags because
they often show that the real consequences of the problem were not
understood.

Christian