RFR(M) : 7104565 : trim jprt build targets

[John Rose]

On Apr 4, 2013, at 7:41 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> It was very long broken (before 1.5) and never was repaired. It was used before we had decent profiling tools. Just delete all 'profiled' related files.

I agree.  Profiled has been dead for about 9 years.  Time for it to go away!

— John

P.S.  FTR, here are some messages from the last time we tried to kill it:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-March/001446.html

The file reorder.sh was a remaining mention of the profiled build in 2009 but it is gone now.

Begin forwarded message:

From: John Rose <John.Rose at Sun.COM>
Subject: Re: Pls review 6813274 (M)
Date: March 16, 2009 4:24:37 PM PDT
To: Paul Hohensee <Paul.Hohensee at Sun.COM>

The Sun analyzer generates mapfiles from collector experiment records obtained from the real JVM, without special compilation.

The last non-incremental change, I think, was Fred Oliver regenerating them in 2004 for bug 5075485.  See:
 /net/jano2.sfbay/export2/hotspot/ws/main/c2_baseline/build/solaris/makefiles/SCCS/s.reorder_COMPILER1_i486

Nobody updating that work will care about prepackaged "profiled" builds if they can use the analyzer.

OTOH, I had forgotten about reorder.sh.  (5 years is a long time.)  The script is very manual and is bit-rotten.  The libmcount sources it refers to no longer exist (apparently) in either the open or closed repos.

So I still say get rid of the build directories from buildatree, but leave make/*/makefiles/profiled.make in place for reference.  The next time somebody refreshes the map files, they'll have all the information the WS can supply, and they'll need to figure out how to use today's tools to build today's mapfile.

-- John

On Mar 16, 2009, at 3:35 PM, Paul Hohensee wrote:

> I rummaged around and discovered that solaris/reorder.sh uses the profiled
> vms to generate the linker mapfiles used to reorder libjvm.so.  Can you think
> of another way to do this?  Or does it even matter anymore?
> 
> Paul
> 
> John Rose wrote:
>> On Mar 16, 2009, at 5:51 AM, Paul Hohensee wrote:
>> 
>>> Thanks for the review.  I'll remove the profiled targets.
>> 
>> I owe you one for taking that off my conscience!  -- John



Begin forwarded message:

From: Paul Hohensee <Paul.Hohensee at Sun.COM>
Subject: Re: Pls review 6813274 (M)
Date: March 16, 2009 4:27:51 PM PDT
To: John Rose <John.Rose at Sun.COM>

ok.  I'll leave reorder.sh in place too, with a note at the top to use the collector instead.

paul

John Rose wrote:
> 
> The Sun analyzer generates mapfiles from collector experiment records obtained from the real JVM, without special compilation. 
> 
> The last non-incremental change, I think, was Fred Oliver regenerating them in 2004 for bug 5075485.  See: 
>   /net/jano2.sfbay/export2/hotspot/ws/main/c2_baseline/build/solaris/makefiles/SCCS/s.reorder_COMPILER1_i486 
> 
> Nobody updating that work will care about prepackaged "profiled" builds if they can use the analyzer. 
> 
> OTOH, I had forgotten about reorder.sh.  (5 years is a long time.)  The script is very manual and is bit-rotten.  The libmcount sources it refers to no longer exist (apparently) in either the open or closed repos. 
> 
> So I still say get rid of the build directories from buildatree, but leave make/*/makefiles/profiled.make in place for reference.  The next time somebody refreshes the map files, they'll have all the information the WS can supply, and they'll need to figure out how to use today's tools to build today's mapfile. 
> 
> -- John 
> 
> On Mar 16, 2009, at 3:35 PM, Paul Hohensee wrote: 
> 
>> I rummaged around and discovered that solaris/reorder.sh uses the profiled 
>> vms to generate the linker mapfiles used to reorder libjvm.so.  Can you think 
>> of another way to do this?  Or does it even matter anymore? 
>> 
>> Paul 
>> 
>> John Rose wrote: 
>>> On Mar 16, 2009, at 5:51 AM, Paul Hohensee wrote: 
>>> 
>>>> Thanks for the review.  I'll remove the profiled targets. 
>>> 
>>> I owe you one for taking that off my conscience!  -- John 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130406/1578b41b/attachment.html