From rgougol at email.sjsu.edu  Wed Nov 21 01:49:34 2007
From: rgougol at email.sjsu.edu (rgougol at email.sjsu.edu)
Date: Wed, 21 Nov 2007 01:49:34 -0800
Subject: 6559156: My favorite defect
Message-ID: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>



Hello everybody,

I am trying and hoping to remove the defect 6559156,
http://bugs.sun.com/view_bug.do?bug_id=6559156. In fact, I am supposed to have a
contribution by the next two weeks as a requirement of my course CS286: Open
Source Development, http://www.horstmann.com/sjsu/cs286/gs.html. Will I have the
chance? If not, would you provide me an alternative defect removal or RFE as
soon as possible. 

My assumption is that the defect exists in file /src/share/vm/opto/subnode.cpp
within optimizations of integer cmp. I wish I could trace the server compiler at
this file using GDB. However, while trace virtual machine launcher of openjdk 
fastdebug with GDB, it produces a new process and then goes beyond the control.
Can you tell me how I may trace the C2 optimizations with GDB and how to put the
break point for the new process that is produced using GDB?

Sincerely,

Nima Rouhollah Gougol, Graduate Student
Computer Science Department
San Jose State University


From gbenson at redhat.com  Wed Nov 21 02:06:24 2007
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 21 Nov 2007 10:06:24 +0000
Subject: 6559156: My favorite defect
In-Reply-To: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>
References: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>
Message-ID: <20071121100623.GB3788@redhat.com>

rgougol at email.sjsu.edu wrote:
> I wish I could trace the server compiler at this file using
> GDB. However, while trace virtual machine launcher of openjdk
> fastdebug with GDB, it produces a new process and then goes
> beyond the control.  Can you tell me how I may trace the C2
> optimizations with GDB and how to put the break point for the
> new process that is produced using GDB?

  (gdb) help set follow-fork-mode
  Set debugger response to a program call of fork or vfork.
  A fork or vfork creates a new process.  follow-fork-mode can be:
    parent  - the original process is debugged after a fork
    child   - the new process is debugged after a fork
  The unfollowed process will continue to run.
  By default, the debugger will follow the parent process.

Cheers,
Gary


From volker.simonis at gmail.com  Wed Nov 21 02:08:09 2007
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 21 Nov 2007 11:08:09 +0100
Subject: 6559156: My favorite defect
In-Reply-To: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>
References: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>
Message-ID: <d65861880711210208h3809f1ebkbd291b9cb9be0db9@mail.gmail.com>

Hi Nima,

see this posting:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-October/000175.html

Regards,
Volker

On 11/21/07, rgougol at email.sjsu.edu <rgougol at email.sjsu.edu> wrote:
>
>
> Hello everybody,
>
> I am trying and hoping to remove the defect 6559156,
> http://bugs.sun.com/view_bug.do?bug_id=6559156. In fact, I am supposed to have a
> contribution by the next two weeks as a requirement of my course CS286: Open
> Source Development, http://www.horstmann.com/sjsu/cs286/gs.html. Will I have the
> chance? If not, would you provide me an alternative defect removal or RFE as
> soon as possible.
>
> My assumption is that the defect exists in file /src/share/vm/opto/subnode.cpp
> within optimizations of integer cmp. I wish I could trace the server compiler at
> this file using GDB. However, while trace virtual machine launcher of openjdk
> fastdebug with GDB, it produces a new process and then goes beyond the control.
> Can you tell me how I may trace the C2 optimizations with GDB and how to put the
> break point for the new process that is produced using GDB?
>
> Sincerely,
>
> Nima Rouhollah Gougol, Graduate Student
> Computer Science Department
> San Jose State University
>


From gbenson at redhat.com  Mon Nov 26 07:04:57 2007
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 26 Nov 2007 15:04:57 +0000
Subject: Bug in LIRGenerator::generate_address on sparc?
Message-ID: <20071126150456.GB3877@redhat.com>

Hi all,

I'm currently working on porting c1 to PPC.  I copied the sparc
implementation of LIRGenerator::generate_address, and at first
I thought it was wasting a register when called with a register
index, nonzero shift and nonzero simm13 displacement, but as I
looked at it it seems broken.  It does this:

  LIR_Opr tmp = new_register(T_INT);
  __ add(tmp, LIR_OprFact::intConst(disp), tmp);

which as far as I can see is starting with a random value in tmp.
I guess this particular case doesn't get used, but here is my
(untested) fix for both the bug and the register wastage.

Cheers,
Gary
-------------- next part --------------
diff -r 8bf719a5aa0c openjdk/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
--- a/openjdk/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp	Mon Nov 26 14:56:30 2007 +0000
+++ b/openjdk/hotspot/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp	Mon Nov 26 14:57:58 2007 +0000
@@ -149,11 +149,17 @@ LIR_Address* LIRGenerator::generate_addr
       index = tmp;
     }
     if (disp != 0) {
-      LIR_Opr tmp = new_register(T_INT);
       if (Assembler::is_simm13(disp)) {
-        __ add(tmp, LIR_OprFact::intConst(disp), tmp);
-        index = tmp;
+        if (shift > 0) {
+          __ add(index, LIR_OprFact::intConst(disp), index);
+        }
+        else {
+          LIR_Opr tmp = new_register(T_INT);
+          __ add(index, LIR_OprFact::intConst(disp), tmp);    
+          index = tmp;
+        }
       } else {
+        LIR_Opr tmp = new_register(T_INT);
         __ move(LIR_OprFact::intConst(disp), tmp);
         __ add(tmp, index, tmp);
         index = tmp;

From dipl.andreas at googlemail.com  Mon Nov 26 07:12:48 2007
From: dipl.andreas at googlemail.com (Chmielewski Andreas)
Date: Mon, 26 Nov 2007 16:12:48 +0100
Subject: scheduling of compilation task
Message-ID: <13adfe140711260712x24127763kab2f4ef1e6a10cdc@mail.gmail.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20071126/a1315241/attachment.html 

From Steve.Goldman at Sun.COM  Mon Nov 26 12:59:03 2007
From: Steve.Goldman at Sun.COM (steve goldman)
Date: Mon, 26 Nov 2007 15:59:03 -0500
Subject: 6559156: My favorite defect
In-Reply-To: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>
References: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>
Message-ID: <474B3397.8010200@sun.com>

rgougol at email.sjsu.edu wrote:
> 
> Hello everybody,
> 
> I am trying and hoping to remove the defect 6559156,
> http://bugs.sun.com/view_bug.do?bug_id=6559156. In fact, I am supposed to have a
> contribution by the next two weeks as a requirement of my course CS286: Open
> Source Development, http://www.horstmann.com/sjsu/cs286/gs.html. Will I have the
> chance? If not, would you provide me an alternative defect removal or RFE as
> soon as possible. 

You should try an pick another defect.
> 
> My assumption is that the defect exists in file /src/share/vm/opto/subnode.cpp
> within optimizations of integer cmp. I wish I could trace the server compiler at
> this file using GDB. 

My understanding is that is an incorrect assumption and that the problem 
is related to the guard expressions created in order to create pre/post 
loops and unrolling and that the fix is rather complicated.


-- 
Steve


From Thomas.Rodriguez at Sun.COM  Mon Nov 26 15:52:22 2007
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Mon, 26 Nov 2007 15:52:22 -0800
Subject: 6559156: My favorite defect
In-Reply-To: <474B3397.8010200@sun.com>
References: <1195638574.4743ff2eabda4@web-mail.sjsu.edu>
	<474B3397.8010200@sun.com>
Message-ID: <474B5C36.6070507@sun.com>

I would agree.  That bug is not for beginners since it's really a loop 
optimization bug.

tom

steve goldman wrote:
> rgougol at email.sjsu.edu wrote:
>>
>> Hello everybody,
>>
>> I am trying and hoping to remove the defect 6559156,
>> http://bugs.sun.com/view_bug.do?bug_id=6559156. In fact, I am supposed 
>> to have a
>> contribution by the next two weeks as a requirement of my course 
>> CS286: Open
>> Source Development, http://www.horstmann.com/sjsu/cs286/gs.html. Will 
>> I have the
>> chance? If not, would you provide me an alternative defect removal or 
>> RFE as
>> soon as possible. 
> 
> You should try an pick another defect.
>>
>> My assumption is that the defect exists in file 
>> /src/share/vm/opto/subnode.cpp
>> within optimizations of integer cmp. I wish I could trace the server 
>> compiler at
>> this file using GDB. 
> 
> My understanding is that is an incorrect assumption and that the problem 
> is related to the guard expressions created in order to create pre/post 
> loops and unrolling and that the fix is rather complicated.
> 
> 


From Thomas.Rodriguez at Sun.COM  Mon Nov 26 16:59:06 2007
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Mon, 26 Nov 2007 16:59:06 -0800
Subject: Bug in LIRGenerator::generate_address on sparc?
In-Reply-To: <20071126150456.GB3877@redhat.com>
References: <20071126150456.GB3877@redhat.com>
Message-ID: <474B6BDA.5020409@sun.com>

That does indeed look wrong.  I don't think your changes to reduce 
register wastage are a good idea though.  Keep in mind that these are 
virtual registers and should generally be created every time a new value 
is defined.  They should never be reused for multiple defs otherwise you 
may be killing a value which is used in some later part of the code. 
The allocator should be a reasonable job of reusing registers for you 
particularly within a basic block.  Are you see problems caused by these 
extra virtual registers?

Anyway, that path doesn't appear to currently be used but I think the 
right fix is simply this:

** /tmp/geta2158       Mon Nov 26 16:53:49 2007
--- c1_LIRGenerator_sparc.cpp   Mon Nov 26 16:49:48 2007
***************
*** 151,157 ****
       if (disp != 0) {
         LIR_Opr tmp = new_register(T_INT);
         if (Assembler::is_simm13(disp)) {
!         __ add(tmp, LIR_OprFact::intConst(disp), tmp);
           index = tmp;
         } else {
           __ move(LIR_OprFact::intConst(disp), tmp);
--- 151,157 ----
       if (disp != 0) {
         LIR_Opr tmp = new_register(T_INT);
         if (Assembler::is_simm13(disp)) {
!         __ add(index, LIR_OprFact::intConst(disp), tmp);
           index = tmp;
         } else {
           __ move(LIR_OprFact::intConst(disp), tmp);

I'll file a bug for this.

tom


Gary Benson wrote:
> Hi all,
> 
> I'm currently working on porting c1 to PPC.  I copied the sparc
> implementation of LIRGenerator::generate_address, and at first
> I thought it was wasting a register when called with a register
> index, nonzero shift and nonzero simm13 displacement, but as I
> looked at it it seems broken.  It does this:
> 
>   LIR_Opr tmp = new_register(T_INT);
>   __ add(tmp, LIR_OprFact::intConst(disp), tmp);
> 
> which as far as I can see is starting with a random value in tmp.
> I guess this particular case doesn't get used, but here is my
> (untested) fix for both the bug and the register wastage.
> 
> Cheers,
> Gary
> 


From gbenson at redhat.com  Tue Nov 27 02:00:08 2007
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 27 Nov 2007 10:00:08 +0000
Subject: Bug in LIRGenerator::generate_address on sparc?
In-Reply-To: <474B6BDA.5020409@sun.com>
References: <20071126150456.GB3877@redhat.com> <474B6BDA.5020409@sun.com>
Message-ID: <20071127100008.GA3917@redhat.com>

Tom Rodriguez wrote:
> That does indeed look wrong.  I don't think your changes to reduce
> register wastage are a good idea though.  Keep in mind that these
> are virtual registers and should generally be created every time a
> new value is defined.  They should never be reused for multiple defs
> otherwise you may be killing a value which is used in some later
> part of the code.  The allocator should be a reasonable job of
> reusing registers for you particularly within a basic block.  Are
> you see problems caused by these extra virtual registers?

Ah, I didn't realise they were virtual.  That makes a lot more sense.

Cheers,
Gary


From rgougol at email.sjsu.edu  Thu Nov 29 08:23:16 2007
From: rgougol at email.sjsu.edu (rgougol at email.sjsu.edu)
Date: Thu, 29 Nov 2007 08:23:16 -0800
Subject: Defect 6612732
Message-ID: <1196353396.474ee774460b6@web-mail.sjsu.edu>


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 Chuck.Rasbold at Sun.COM  Thu Nov 29 08:36:17 2007
From: Chuck.Rasbold at Sun.COM (Chuck Rasbold)
Date: Thu, 29 Nov 2007 08:36:17 -0800
Subject: Defect 6612732
In-Reply-To: <1196353396.474ee774460b6@web-mail.sjsu.edu>
References: <1196353396.474ee774460b6@web-mail.sjsu.edu>
Message-ID: <474EEA81.3070705@Sun.COM>

To reproduce the problem, have you tried using the flags "-client -Xcomp 
-XX:CompileThreshold=100 -XX:UseSSE=1" ?

-- Chuck Rasbold

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 Thomas.Rodriguez at Sun.COM  Thu Nov 29 11:44:56 2007
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 29 Nov 2007 11:44:56 -0800
Subject: Defect 6612732
In-Reply-To: <1196353396.474ee774460b6@web-mail.sjsu.edu>
References: <1196353396.474ee774460b6@web-mail.sjsu.edu>
Message-ID: <474F16B8.4030805@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 rgougol at email.sjsu.edu  Thu Nov 29 15:34:55 2007
From: rgougol at email.sjsu.edu (rgougol at email.sjsu.edu)
Date: Thu, 29 Nov 2007 15:34:55 -0800
Subject: Defect 6612732
Message-ID: <1196379295.474f4c9fa1965@web-mail.sjsu.edu>

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 Thomas.Rodriguez at Sun.COM  Thu Nov 29 17:32:11 2007
From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez)
Date: Thu, 29 Nov 2007 17:32:11 -0800
Subject: Defect 6612732
In-Reply-To: <1196379295.474f4c9fa1965@web-mail.sjsu.edu>
References: <1196379295.474f4c9fa1965@web-mail.sjsu.edu>
Message-ID: <474F681B.3070706@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
> 
>