I have watched this thread for some time. Yes, SSD should be faster but
Pete's build times are just incredibly slow and there must be some other
reason.
I just open my Lenovo t410 (i5 2.6GHz, 8GB RAM, HDD) that has been
asleep for the last two days, mkdir a new directory, run configure and
"m
Dell laptop (Win7, i5-2520M 2.5Ghz, 8GB RAM) + Samsung 840 PRO SSD 256GB.
The JDK source tree is excluded from virus scan.
The source has all the open and closed parts. I ran configure and "make
all" with all default parameters.
- Build times ---
Start 2013-08-28 20:33:57
End 2013-
Pete,
By the way, for the purposes of testing your build speed, instead of
spending a long time building JDK8, maybe you can just build hotspot.
It's not completely proportional but would give you some ideas whether
you should consider getting another laptop :-)
Start Menu -> All Programs ->
On 08/28/2013 11:47 AM, Pete Brunet wrote:
Thanks Tim,
On 8/27/13 6:44 PM, Tim Bell wrote:
Good advice on the virus scanning front, and of course every bit helps.
Also keep in mind that laptop components often sacrifice performance
in favor of saving space, power, and battery life. A laptop i
Hello all;
JDK-8023491 included a change which attempted to adjust the location that the
langtools/test/Makefile used to write test results. This change conflicted with
how the test/Makefiles are used by important scripts. This change backs out the
langtools testing output location changes whic
Dmitry,
I don't think this is something that should be handled at the configure
level. Hotspot compiler flags are handled in the hotspot makefiles. This
should be in gcc.make.
BTW your changeset should include the generated-configure.sh file not
configure. And you would also need to regenera
On 29/08/2013 7:44 AM, Pete Brunet wrote:
On 8/28/13 2:11 PM, Tim Bell wrote:
On 08/28/13 11:47 AM, Pete Brunet wrote:
Since winset ran in a separate window and it closed before I could
use the info I needed this advice:
http://superuser.com/questions/93826/winsat-command-line-closes-too-fast
On 8/28/13 2:11 PM, Tim Bell wrote:
> On 08/28/13 11:47 AM, Pete Brunet wrote:
>
>> Since winset ran in a separate window and it closed before I could
>> use the info I needed this advice:
>> http://superuser.com/questions/93826/winsat-command-line-closes-too-fast
>> Running as admin solved it.
>
On 8/28/13 6:21 AM, Erik Joelsson wrote:
> Nice to see improvement, but it's still far from where it should be.
> For comparison, here are my build times on a similar, but probably
> slower, laptop. Lenovo T410, i5 M 520 2.40GHz and 4GB ram, no ssd.
> This laptop has no anti virus scanning install
On 08/28/13 11:47 AM, Pete Brunet wrote:
Since winset ran in a separate window and it closed before I could use
the info I needed this advice:
http://superuser.com/questions/93826/winsat-command-line-closes-too-fast
Running as admin solved it.
Or open a command window and type in the command
Thanks Tim,
On 8/27/13 6:44 PM, Tim Bell wrote:
> Good advice on the virus scanning front, and of course every bit helps.
>
> Also keep in mind that laptop components often sacrifice performance
> in favor of saving space, power, and battery life. A laptop is not a
> workstation.
>
> If your lapt
Thanks Coleen for the review. I'm cc'ing openjdk distribution lists on
this reply.
Lois
On 8/28/2013 2:11 PM, Coleen Phillimore wrote:
Looks good.
Coleen
On 8/28/2013 1:56 PM, Lois Foltan wrote:
Please review the updated webrev:
open webrev at http://cr.openjdk.java.net/~hseigel/bug
Forwarding to include the openjdk distribution lists.
Lois
Original Message
Subject: Re: RFR JDK-8022407 sun/misc/CopyMemory.java fails with
SIGSEGV in Unsafe_SetByte+0x35
Date: Wed, 28 Aug 2013 14:10:08 -0400
From: Lois Foltan
Organization: Oracle Corporation
To:
Please review the updated webrev:
open webrev at http://cr.openjdk.java.net/~hseigel/bug_jdk8022407.2/
Bug:
bug link at https://bugs.openjdk.java.net/browse/JDK-8022407
Summary of fix:
The JDK 8 build on MacOS, when built with the Xcode 4.6.2 clang++
compiler, exhibited a compiler
current AC_PREREQ is 2.61, fwiw, which is from 2006. Latest Autoconf is
2.69 from 2012, preceded by 2.68 from 2010.
It may be useful to limit the variety of autoconfs in use by setting
AC_PREREQ to, say, 2.68.
>>> Eeek! 2.61! I believe our current minimum is 2.67 (thoug
On 28/08/2013 16:47, Erik Joelsson wrote:
On 2013-08-28 17:16, Dalibor Topic wrote:
On 8/28/13 4:59 PM, Mike Duigou wrote:
On Aug 28 2013, at 07:42 , Dalibor Topic wrote:
current AC_PREREQ is 2.61, fwiw, which is from 2006. Latest Autoconf
is 2.69 from 2012, preceded by 2.68 from 2010.
It
On 2013-08-28 17:16, Dalibor Topic wrote:
On 8/28/13 4:59 PM, Mike Duigou wrote:
On Aug 28 2013, at 07:42 , Dalibor Topic wrote:
current AC_PREREQ is 2.61, fwiw, which is from 2006. Latest Autoconf is 2.69
from 2012, preceded by 2.68 from 2010.
It may be useful to limit the variety of auto
On 8/28/13 4:59 PM, Mike Duigou wrote:
>
> On Aug 28 2013, at 07:42 , Dalibor Topic wrote:
>
>> current AC_PREREQ is 2.61, fwiw, which is from 2006. Latest Autoconf is 2.69
>> from 2012, preceded by 2.68 from 2010.
>>
>> It may be useful to limit the variety of autoconfs in use by setting
>> A
On Aug 28 2013, at 07:42 , Dalibor Topic wrote:
> current AC_PREREQ is 2.61, fwiw, which is from 2006. Latest Autoconf is 2.69
> from 2012, preceded by 2.68 from 2010.
>
> It may be useful to limit the variety of autoconfs in use by setting
> AC_PREREQ to, say, 2.68.
Eeek! 2.61! I believe o
Pete,
One of ways to get rid of antivirus is to install VirtualBox, another
copy of windows into VirtualBox and do all unsafe internet access from
within this box.
-Dmitry
On 2013-08-09 18:44, Pete Brunet wrote:
> My product is Norton 360. To turn it off I right click on the Norton
> 360 icon
current AC_PREREQ is 2.61, fwiw, which is from 2006. Latest Autoconf is 2.69
from 2012, preceded by 2.68 from 2010.
It may be useful to limit the variety of autoconfs in use by setting AC_PREREQ
to, say, 2.68.
cheers,
dalibor topic
On 8/28/13 10:29 AM, Chris Hegarty wrote:
> Sounds good to m
On 08/28/2013 07:47 AM, Erik Joelsson wrote:
> While installing a new system I too stumbled over the help messages from
> configure and decided to try and fix them this time. I believe that
> these suggestions will actually work and cover everything.
>
> http://cr.openjdk.java.net/~erikj/8003162/w
Erik:
While installing a new system I too stumbled over the help messages
from configure and decided to try and fix them this time. I believe
that these suggestions will actually work and cover everything.
http://cr.openjdk.java.net/~erikj/8003162/webrev.root.01/
Looks good to me for Linux.
Hello Ivan - see my replies inline:
I looked today at the readme doc for JDK 8 and came up with a couple of comments
I'll take a guess that you are referring to the top level
README-builds.html file
1) The doc does not mention nashhorn that is being pulled along with the other
repos, perh
On 2013-08-28 15:18, Ivan Krylov wrote:
I should have mentioned that the original subject is about the the "OpenJDK Build
README" document
On Aug 28, 2013, at 5:16 PM, Ivan Krylov
wrote:
Hello,
I looked today at the readme doc for JDK 8 and came up with a couple of comments
1) The doc d
Hi Everyone,
Please review small fix
webrev:
http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/
CR:
http://bugs.sun.com/view_bug.do?bug_id=8022617
Gory details:
bsd_x86_64.s use macro to deal with OS X specific things.
llvm-gcc preprocess .s and .S files and doesn't support .s
I should have mentioned that the original subject is about the the "OpenJDK
Build README" document
On Aug 28, 2013, at 5:16 PM, Ivan Krylov
wrote:
> Hello,
>
> I looked today at the readme doc for JDK 8 and came up with a couple of
> comments
> 1) The doc does not mention nashhorn that is b
Hello,
I looked today at the readme doc for JDK 8 and came up with a couple of comments
1) The doc does not mention nashhorn that is being pulled along with the other
repos, perhaps it is worth mentioning in the doc.
2) I was under impression that for both JDK7 and JDK8 SP1 of MS Visual Studio
i
While installing a new system I too stumbled over the help messages from
configure and decided to try and fix them this time. I believe that
these suggestions will actually work and cover everything.
http://cr.openjdk.java.net/~erikj/8003162/webrev.root.01/
http://bugs.sun.com/view_bug.do?bug_
On 28/08/2013 00:17, Mike Duigou wrote:
Hello all;
I have updated the changeset for this issue based upon feedback from the
earlier version. As a result of intervening work this version contains even
more cleanup.
http://cr.openjdk.java.net/~mduigou/JDK-8015068/1/webrev/
Since the last revis
Nice to see improvement, but it's still far from where it should be. For
comparison, here are my build times on a similar, but probably slower,
laptop. Lenovo T410, i5 M 520 2.40GHz and 4GB ram, no ssd. This laptop
has no anti virus scanning installed.
- Build times ---
Start 2013-08-2
Sounds good to me.
We could start by reviewers keeping an eye out for changes in version,
when reviewing fixes requiring updates to generated-configure.
-Chris.
On 28/08/2013 00:43, Mike Duigou wrote:
A possible policy that would also gently (glacially?) roll the autoconf version forward ove
32 matches
Mail list logo