Usage of C++ features

Mikael Gerdin mikael.gerdin at oracle.com
Fri Feb 7 04:33:19 PST 2014


Hi Goetz,

On Friday 07 February 2014 12.01.15 Lindenmaier, Goetz wrote:
> Hi,
> 
> Thanks a lot for all the feedback!  To summarize, there is nothing in
> the pipe besides the exceptions in the compiler, but the desire to
> use new features/stl once compiler issues are resolved.
> 
> > I have this lingering feeling that we shouldn't need to use template
> > template parameters for the binaryTreeDictionary code but I haven't
> > experimented with
> Yes Mikael, you are right.  You don't need them.
> I would appreciate a lot if the following webrev would be
> considered as contribution to jdk9 and jdk8u20.
> http://cr.openjdk.java.net/~goetz/webrevs/rm_tmptmp_param/
> 
> If I don't get any objections I'll open a bug and mail a proper
> RFR?

As I hinted in my mail, I'd welcome this change.

I had a quick look through the patches and I noticed that you removed a 
get_chunk from binaryTreeDictionary.cpp, you should remember to point that out 
when you send the RFR.

Also, you forgot a
-    dictionary()->get_chunk(word_size, 
FreeBlockDictionary<Metablock>::atLeast);
+    dictionary()->get_chunk(word_size, 
FreeBlockDictionary<Metablock>::exactly);

Do you have any further input on this?
Are you running with exactly instead of atLeast here or is this just a mis-
merge? We'd appreciate any feedback you have about the policy in this code.

/Mikael


> 
> I compiled it on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 with
> SS12u1. I tested dbg, fdbg and opt builds. I did some simple tests. 
> Tonight the change will run with all our tests on the ppc port, build on
> windows and sparc included.
> 
> Best regards,
>   Goetz.
> 
> 
> 
> 
> -----Original Message-----
> From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com]
> Sent: Donnerstag, 6. Februar 2014 12:56
> To: hotspot-dev at openjdk.java.net
> Cc: David Holmes; Lindenmaier, Goetz
> Subject: Re: Usage of C++ features
> 
> On Thursday 06 February 2014 21.27.51 David Holmes wrote:
> > Hi Goetz,
> > 
> > On 6/02/2014 8:33 PM, Lindenmaier, Goetz wrote:
> > > Hi,
> > > 
> > > wrt. our (SAPs) various ports which are running on old machines, built
> > > with old compilers for compatibility, I would like to find out about
> > > the OpenJDK policy regarding 'real' C++ features.
> > 
> > I don't think there is such a thing as "OpenJDK policy" for this. Things
> > need to be evaluated on their merits taking into account a range of
> > factors, including compiler compatibility issues.
> > 
> > > Recently, we found increasing usage of C++ features.
> > > 
> > > -          'throw()'  in nmethod operator new
> > 
> > > -          usage of namespace std::
> > AFAICS only std::nothrow is in use, which combines with the use of
> > throw() in numerous (most?) operator new definitions to make it clear
> > that these don't throw any exceptions.
> > 
> > That said the compiler folk have expressed interest in using C++
> > exceptions within the compiler.
> > 
> > > -          template template parameters in binaryTreeDictionary.hpp|cpp
> > 
> > Can't comment on that.
> 
> I have this lingering feeling that we shouldn't need to use template
> template parameters for the binaryTreeDictionary code but I haven't
> experimented with it.
> I'd prefer to simplify that just for the sake of sanity.
> 
> /Mikael
> 
> > > We would like to know whether you are planning to increase the
> > > usage of C++ or even use C++11 features.  Or, whether you are planning
> > > to keep the policy to avoid C++ features that caused problems to
> > > compilers in the past.
> > 
> > I can envisage usage of C++11 atomics at some point. But it depends on
> > it being supported across sufficient compilers. What else is coming in
> > C++11?
> > 
> > I think everything has to be considered on a case-by-case basis. You
> > presumably have some things in mind ?
> > 
> > Just my 2c. I'm not a policy maker. :)
> > 
> > Cheers,
> > David
> > 
> > > Best regards,
> > > 
> > >    Goetz.



More information about the hotspot-dev mailing list