Re: RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[Erik Joelsson]

I'm OK with this change.

/Erik

On 2013-08-16 18:51, Staffan Larsen wrote:

This failure happens when compiling with the VS 2012 compiler. The attach code 
relies on the order of two methods in the compiled binary and VS 2012 changed 
that order. The solution used is the linker flag /ORDER [1] which allows us to 
specify the order in which methods are laid out in the binary image. Since the 
flag only operates on non-static methods, the methods have been made non-static 
and also changed name so that they will not clash with other methods.

webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/

The change has been tested with both VS 2010 and VS 2012.

Thanks,
/Staffan


[1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx

Re: RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[Staffan Larsen]

On 19 aug 2013, at 06:12, David Holmes  wrote:

> On 17/08/2013 2:51 AM, Staffan Larsen wrote:
>> This failure happens when compiling with the VS 2012 compiler. The attach 
>> code relies on the order of two methods in the compiled binary and VS 2012 
>> changed that order. The solution used is the linker flag /ORDER [1] which 
>> allows us to specify the order in which methods are laid out in the binary 
>> image. Since the flag only operates on non-static methods, the methods have 
>> been made non-static and also changed name so that they will not clash with 
>> other methods.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/
>> 
>> The change has been tested with both VS 2010 and VS 2012.
> 
> I wonder if simply changing from static to non-static would have been 
> sufficient? Of course still no guarantee that future versions of the compiler 
> would preserve the same order in that case; but then what guarantees do we 
> have that the weird @4 name mangling will remain the same?

The name decoration used by the windows compiler is stable and well-defined [1] 
[2] . I'm not sure it is official, but enough tools depend on it that it will 
not be changed. In short the number after the @ sign is the number of bytes 
passed on the stack for the calling convention of the specific platform. 

/Staffan

[1] 
http://en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows
[2] http://en.wikibooks.org/wiki/X86_Disassembly/Calling_Conventions#STDCALL


> 
> Thanks,
> David
> 
>> Thanks,
>> /Staffan
>> 
>> 
>> [1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx
>> 

RFR: 8023216: Feedback on README-builds.html

[Erik Joelsson]

Thanks for the feedback!

I took most of it and made into a change. Also removed some obsolete 
parts that I stumbled over.


Warn is supposed to be quiet, but at least hotspot is still being quite 
noisy.


/Erik

On 2013-08-06 01:18, Dan Smith wrote:

I'm building for the first time under the new infrastructure (late to the 
party, I know).  I appreciate the comprehensive readme page.  Here's a list of 
minor points of feedback:

"The set of repositories and what they contain": need to add nashorn

"warn — Default and very quiet": I presume this is still an in-progress goal?  
I'm seeing almost 3000 lines of text in a fresh build (including over 1000 from 'images')

---

Some copy editing:

"each repository is it's own independent repository": it's ->  its

"Insure that GNU make": insure ->  ensure

"rather thane excludes": thane ->  than

"Other depends on pieces of code": other depends ->  others depend

"for all classes that contains constants": contains ->  contain

"we have missed to add support": missed ->  neglected

hg: jdk8/build: 8023156: make dist-clean should remove javacservers directory

[erik . joelsson]

Changeset: f10f673d9b17
Author:igerasim
Date:  2013-08-16 14:43 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/rev/f10f673d9b17

8023156: make dist-clean should remove javacservers directory
Reviewed-by: erikj

! common/makefiles/Main.gmk

Re: RFR: 8023216: Feedback on README-builds.html

[Erik Joelsson]

And again, here we go:

http://cr.openjdk.java.net/~erikj/8023216/webrev.root.01/

/Erik

On 2013-08-19 11:05, Erik Joelsson wrote:

Thanks for the feedback!

I took most of it and made into a change. Also removed some obsolete 
parts that I stumbled over.


Warn is supposed to be quiet, but at least hotspot is still being 
quite noisy.


/Erik

On 2013-08-06 01:18, Dan Smith wrote:
I'm building for the first time under the new infrastructure (late to 
the party, I know).  I appreciate the comprehensive readme page.  
Here's a list of minor points of feedback:


"The set of repositories and what they contain": need to add nashorn

"warn — Default and very quiet": I presume this is still an 
in-progress goal?  I'm seeing almost 3000 lines of text in a fresh 
build (including over 1000 from 'images')


---

Some copy editing:

"each repository is it's own independent repository": it's ->  its

"Insure that GNU make": insure ->  ensure

"rather thane excludes": thane ->  than

"Other depends on pieces of code": other depends ->  others depend

"for all classes that contains constants": contains ->  contain

"we have missed to add support": missed ->  neglected

Re: RFR: 8023216: Feedback on README-builds.html

[Anthony Petrov]

Hi Erik,

The fix looks fine to me.

--
best regards,
Anthony

On 08/19/13 16:43, Erik Joelsson wrote:

And again, here we go:

http://cr.openjdk.java.net/~erikj/8023216/webrev.root.01/

/Erik

On 2013-08-19 11:05, Erik Joelsson wrote:

Thanks for the feedback!

I took most of it and made into a change. Also removed some obsolete
parts that I stumbled over.

Warn is supposed to be quiet, but at least hotspot is still being
quite noisy.

/Erik

On 2013-08-06 01:18, Dan Smith wrote:

I'm building for the first time under the new infrastructure (late to
the party, I know). I appreciate the comprehensive readme page.
Here's a list of minor points of feedback:

"The set of repositories and what they contain": need to add nashorn

"warn — Default and very quiet": I presume this is still an
in-progress goal? I'm seeing almost 3000 lines of text in a fresh
build (including over 1000 from 'images')

---

Some copy editing:

"each repository is it's own independent repository": it's -> its

"Insure that GNU make": insure -> ensure

"rather thane excludes": thane -> than

"Other depends on pieces of code": other depends -> others depend

"for all classes that contains constants": contains -> contain

"we have missed to add support": missed -> neglected

Re: RFR: 8023216: Feedback on README-builds.html

[Dalibor Topic]

On 8/19/13 2:43 PM, Erik Joelsson wrote:
> And again, here we go:
> 
> http://cr.openjdk.java.net/~erikj/8023216/webrev.root.01/

A few typos:

javascript -> JavaScript
sourses -> sources

cheers,
dalibor topic


> 
> /Erik
> 
> On 2013-08-19 11:05, Erik Joelsson wrote:
>> Thanks for the feedback!
>>
>> I took most of it and made into a change. Also removed some obsolete parts 
>> that I stumbled over.
>>
>> Warn is supposed to be quiet, but at least hotspot is still being quite 
>> noisy.
>>
>> /Erik
>>
>> On 2013-08-06 01:18, Dan Smith wrote:
>>> I'm building for the first time under the new infrastructure (late to the 
>>> party, I know).  I appreciate the comprehensive readme page.  Here's a list 
>>> of minor points of feedback:
>>>
>>> "The set of repositories and what they contain": need to add nashorn
>>>
>>> "warn — Default and very quiet": I presume this is still an in-progress 
>>> goal?  I'm seeing almost 3000 lines of text in a fresh build (including 
>>> over 1000 from 'images')
>>>
>>> ---
>>>
>>> Some copy editing:
>>>
>>> "each repository is it's own independent repository": it's ->  its
>>>
>>> "Insure that GNU make": insure ->  ensure
>>>
>>> "rather thane excludes": thane ->  than
>>>
>>> "Other depends on pieces of code": other depends ->  others depend
>>>
>>> "for all classes that contains constants": contains ->  contain
>>>
>>> "we have missed to add support": missed ->  neglected



-- 
Oracle 
Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961 

Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment

Jarreorder and classlists

[Erik Joelsson]

Hello,

I wonder if anyone knows more about the jarreorder tool and why we use it?

As I understand it, we have precalculated classlists for each platform 
(most likely outdated) and the tool is used to make sure those classes 
end up in a specific order, last in rt.jar. I assume this is some kind 
of startup time optimization.


I got some help from Claes in the performance team and did a quick run 
of a startup and footprint benchmark, comparing a build with the rt.jar 
reordered as normal and one where I simply turned off this feature and 
let the files end up in the default order. Our preliminary findings show 
that any difference between the two is negligible. Before we declare it 
useless, we might need to test with freshly generated classlists? Does 
anyone know how to generate them? Is there some other benefit of this 
that I might have missed?


I would like to propose removing jarreorder to simplify the build. This 
would also enable faster incremental builds of the images target, by not 
having to rebuild the whole rt.jar every time.


/Erik

Re: Jarreorder and classlists

[Kelly O'Hair]

You should check with the Hotspot runtime team. I seem to recall this might 
have some connection to class data sharing (cds) in the VM.

I agree that we should toss it if it is not needed. I've always wondered if it 
was just a complication we did not need anymore.

-kto

On Aug 19, 2013, at 8:17 AM, Erik Joelsson wrote:

> Hello,
> 
> I wonder if anyone knows more about the jarreorder tool and why we use it?
> 
> As I understand it, we have precalculated classlists for each platform (most 
> likely outdated) and the tool is used to make sure those classes end up in a 
> specific order, last in rt.jar. I assume this is some kind of startup time 
> optimization.
> 
> I got some help from Claes in the performance team and did a quick run of a 
> startup and footprint benchmark, comparing a build with the rt.jar reordered 
> as normal and one where I simply turned off this feature and let the files 
> end up in the default order. Our preliminary findings show that any 
> difference between the two is negligible. Before we declare it useless, we 
> might need to test with freshly generated classlists? Does anyone know how to 
> generate them? Is there some other benefit of this that I might have missed?
> 
> I would like to propose removing jarreorder to simplify the build. This would 
> also enable faster incremental builds of the images target, by not having to 
> rebuild the whole rt.jar every time.
> 
> /Erik

Re: Jarreorder and classlists

[Staffan Larsen]

We did have something similar in JRockit. In that case it was designed to 
increase start up performance. If I remember correctly it only gave measurable 
performance in a _cold_ start - that is when the jar file was not already 
present in the HD cache but had to be read from spinning rust. That may not be 
a relevant case any more.

/Staffan

On 19 aug 2013, at 17:17, Erik Joelsson  wrote:

> Hello,
> 
> I wonder if anyone knows more about the jarreorder tool and why we use it?
> 
> As I understand it, we have precalculated classlists for each platform (most 
> likely outdated) and the tool is used to make sure those classes end up in a 
> specific order, last in rt.jar. I assume this is some kind of startup time 
> optimization.
> 
> I got some help from Claes in the performance team and did a quick run of a 
> startup and footprint benchmark, comparing a build with the rt.jar reordered 
> as normal and one where I simply turned off this feature and let the files 
> end up in the default order. Our preliminary findings show that any 
> difference between the two is negligible. Before we declare it useless, we 
> might need to test with freshly generated classlists? Does anyone know how to 
> generate them? Is there some other benefit of this that I might have missed?
> 
> I would like to propose removing jarreorder to simplify the build. This would 
> also enable faster incremental builds of the images target, by not having to 
> rebuild the whole rt.jar every time.
> 
> /Erik

Re: README-builds.html feedback

[Jonathan Gibbons]

Dan,

It's nice to see other other people being "picky".

-- Jon

On 08/05/2013 04:18 PM, Dan Smith wrote:

I'm building for the first time under the new infrastructure (late to the 
party, I know).  I appreciate the comprehensive readme page.  Here's a list of 
minor points of feedback:

"The set of repositories and what they contain": need to add nashorn

"warn — Default and very quiet": I presume this is still an in-progress goal?  
I'm seeing almost 3000 lines of text in a fresh build (including over 1000 from 'images')

---

Some copy editing:

"each repository is it's own independent repository": it's -> its

"Insure that GNU make": insure -> ensure

"rather thane excludes": thane -> than

"Other depends on pieces of code": other depends -> others depend

"for all classes that contains constants": contains -> contain

"we have missed to add support": missed -> neglected

---

—Dan

Re: RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[serguei.spit...@oracle.com]

The fix looks good.
The Copyright comment of the WindowsVirtualMachine.c**can be updated 
with 2013.


Thanks,
Serguei

On 8/16/13 9:51 AM, Staffan Larsen wrote:

This failure happens when compiling with the VS 2012 compiler. The attach code 
relies on the order of two methods in the compiled binary and VS 2012 changed 
that order. The solution used is the linker flag /ORDER [1] which allows us to 
specify the order in which methods are laid out in the binary image. Since the 
flag only operates on non-static methods, the methods have been made non-static 
and also changed name so that they will not clash with other methods.

webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/

The change has been tested with both VS 2010 and VS 2012.

Thanks,
/Staffan


[1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx

hg: jdk8/build: 8021430: 64 bit JDK build fails on windows 7 due to missing corba source files

[erik . joelsson]

Changeset: dadf49495ab4
Author:erikj
Date:  2013-08-19 10:31 +0200
URL:   http://hg.openjdk.java.net/jdk8/build/rev/dadf49495ab4

8021430: 64 bit JDK build fails on windows 7 due to missing corba source files
Reviewed-by: tbell, katleman

! common/makefiles/IdlCompilation.gmk

Re: RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[Dmitry Samersoff]

Staffan,

It might be better to just use inline assembler to record start and end
of the routine, as nobody guarantee that thread_end is not optimized out
or some function is not inserted in between thread_func and thread_end.

Something like below should work:

First line of thread_func:

_asm(
   jmp End_Of_Func_Label
)

and, when necessary, read opcode at &thread_func (E9 or EB) and extract
imm that comes afterward.

-Dmitry



On 2013-08-16 20:51, Staffan Larsen wrote:
> This failure happens when compiling with the VS 2012 compiler. The attach 
> code relies on the order of two methods in the compiled binary and VS 2012 
> changed that order. The solution used is the linker flag /ORDER [1] which 
> allows us to specify the order in which methods are laid out in the binary 
> image. Since the flag only operates on non-static methods, the methods have 
> been made non-static and also changed name so that they will not clash with 
> other methods.
> 
> webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/
> 
> The change has been tested with both VS 2010 and VS 2012.
> 
> Thanks,
> /Staffan
> 
> 
> [1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

Re: Jarreorder and classlists

[David Holmes]

Hi Erik,

Adding in hotspot-runtime-dev.

There is a lot of history here and I'm not sure who remembers all the 
details - if anyone. There are existing open bugs to re-assess the 
utility of the jarreorder (7032729) and to update the classlists (8005688).


David
--

On 20/08/2013 1:17 AM, Erik Joelsson wrote:

Hello,

I wonder if anyone knows more about the jarreorder tool and why we use it?

As I understand it, we have precalculated classlists for each platform
(most likely outdated) and the tool is used to make sure those classes
end up in a specific order, last in rt.jar. I assume this is some kind
of startup time optimization.

I got some help from Claes in the performance team and did a quick run
of a startup and footprint benchmark, comparing a build with the rt.jar
reordered as normal and one where I simply turned off this feature and
let the files end up in the default order. Our preliminary findings show
that any difference between the two is negligible. Before we declare it
useless, we might need to test with freshly generated classlists? Does
anyone know how to generate them? Is there some other benefit of this
that I might have missed?

I would like to propose removing jarreorder to simplify the build. This
would also enable faster incremental builds of the images target, by not
having to rebuild the whole rt.jar every time.

/Erik

RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated

[David DeHaven]

[CC'ing build-dev for comments on the build system changes]


Finally took the ten minutes to do this backport of JDK-7181710 for JDK 8.

Please review my changeset for JDK-8016096:
http://cr.openjdk.java.net/~ddehaven/8016096/jdk.0/

Issue:
http://bugs.sun.com/view_bug.do?bug_id=8016096

7u issue (more info):
http://bugs.sun.com/view_bug.do?bug_id=7181710

Basically an almost direct backport of the 7u changeset, modified for the new 
build system (much simpler). I also removed X11 toolkit support as Artem (I 
think?) mentioned we will not be shipping with an X11 toolkit for JDK 8. I did 
not touch the old build system as it's slated for removal anyways.

Mac build was fine, submitting a JPRT run to ensure other platforms are not 
affected.

I'll need a sponsor for this one too.

-DrD-

Re: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated

[David DeHaven]

> [CC'ing build-dev for comments on the build system changes]
> 
> 
> Finally took the ten minutes to do this backport of JDK-7181710 for JDK 8.
> 
> Please review my changeset for JDK-8016096:
> http://cr.openjdk.java.net/~ddehaven/8016096/jdk.0/

Oops, I missed a few files in that changeset, namely the updates to AWT source 
that still used JavaVM headers. Will update when done testing.

-DrD-

Re: RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[Staffan Larsen]

Using inline assembly and parsing opcodes seems more brittle than using linker 
flags.

/Staffan

On 19 aug 2013, at 23:10, Dmitry Samersoff  wrote:

> Staffan,
> 
> It might be better to just use inline assembler to record start and end
> of the routine, as nobody guarantee that thread_end is not optimized out
> or some function is not inserted in between thread_func and thread_end.
> 
> Something like below should work:
> 
> First line of thread_func:
> 
> _asm(
>   jmp End_Of_Func_Label
> )
> 
> and, when necessary, read opcode at &thread_func (E9 or EB) and extract
> imm that comes afterward.
> 
> -Dmitry
> 
> 
> 
> On 2013-08-16 20:51, Staffan Larsen wrote:
>> This failure happens when compiling with the VS 2012 compiler. The attach 
>> code relies on the order of two methods in the compiled binary and VS 2012 
>> changed that order. The solution used is the linker flag /ORDER [1] which 
>> allows us to specify the order in which methods are laid out in the binary 
>> image. Since the flag only operates on non-static methods, the methods have 
>> been made non-static and also changed name so that they will not clash with 
>> other methods.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/
>> 
>> The change has been tested with both VS 2010 and VS 2012.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> [1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

Re: RFR(S): 8022071 Some vm/jvmti tests fail because cannot attach to the Java virtual machine

[Staffan Larsen]

Thanks, Serguei. I'll fix the copyright.

/Staffan

On 19 aug 2013, at 20:27, serguei.spit...@oracle.com wrote:

> The fix looks good.
> The Copyright comment of the WindowsVirtualMachine.c can be updated with 2013.
> 
> Thanks,
> Serguei
> 
> On 8/16/13 9:51 AM, Staffan Larsen wrote:
>> This failure happens when compiling with the VS 2012 compiler. The attach 
>> code relies on the order of two methods in the compiled binary and VS 2012 
>> changed that order. The solution used is the linker flag /ORDER [1] which 
>> allows us to specify the order in which methods are laid out in the binary 
>> image. Since the flag only operates on non-static methods, the methods have 
>> been made non-static and also changed name so that they will not clash with 
>> other methods.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8022071/webrev.01/
>> 
>> The change has been tested with both VS 2010 and VS 2012.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> [1] http://msdn.microsoft.com/en-us/library/vstudio/00kh39zz.aspx
>