From david.holmes at oracle.com Mon Jun 2 03:43:04 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 02 Jun 2014 13:43:04 +1000
Subject: [9] RFR (XS) 8044339: wrong comment for FilterSpuriousWakeups
option
In-Reply-To: <5388AA5C.2060207@oracle.com>
References: <53877D90.7090105@oracle.com> <53881F1B.4090805@oracle.com>
<5388AA5C.2060207@oracle.com>
Message-ID: <538BF2C8.3010102@oracle.com>
Hi Lev,
On 31/05/2014 1:57 AM, Lev Priima wrote:
> Thanks for comments, please look at update:
> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.01/
Please generalize the CR summary and description if you are going to
pursue all these changes. But include additional information to clarify
why you made the changes in the os_XXX.cpp files please. On that note
can you please change:
! // We must filter out spurious wakeups.
to
! // We ignore spurious OS wakeups unless FilterSpuriousWakeups is false
In globals.hpp: Note that CompilerThreadHintNoPreempt and
VMThreadHintNoPreempt are actually only meaningful on Solaris. They
guard the call to os::hint_no_preempt which is a no-op except on
Solaris. So those changes should be reverted.
Thanks,
David
> Lev
>
> On 05/30/2014 10:03 AM, David Holmes wrote:
>> Hi Lev,
>>
>> On 30/05/2014 4:33 AM, Lev Priima wrote:
>>> Please review and help me with integration:
>>>
>>> diff -r 102506d9d873 src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hpp Wed May 28 14:42:00 2014 +0400
>>> +++ b/src/share/vm/runtime/globals.hpp Thu May 29 22:29:37 2014 +0400
>>> @@ -1144,7 +1144,7 @@
>>> \
>>> product(bool, FilterSpuriousWakeups,
>>> true, \
>>> "Prevent spurious or premature wakeups from object.wait
>>> " \
>>> - "(Solaris
>>> only)") \
>>> + "(Ignored for
>>> Windows)") \
>>> \
>>
>> Sorry to make life complicated but as I put in the bug report:
>>
>> The "Solaris" part dates from the days when Solaris meant "not
>> Windows". :)
>>
>> A bigger problem here is that the main part of the description:
>>
>> "Prevent spurious or premature wakeups from object.wait "
>>
>> may not match what people expect - it depends on whether "filter"
>> means to remove the item being filtered, or to keep only the item
>> being filtered. It would clearer if it read "When true prevents ..."
>> but even then it is not accurate as this only excludes spurious
>> wakeups from the OS pthread_cond[timed]wait implementation - the JVM
>> can still induce its own "spurious wakeups". So the better description
>> would be:
>>
>> "When true prevents OS-level spurious, or premature, wakeups from
>> Object.wait"
>>
>> But it should also be noted that where this flag is checked there is
>> an even more inaccurate comment:
>>
>> // The underlying Solaris implementation, cond_timedwait, admits
>> // spurious/premature wakeups, but the JLS/JVM spec prevents the
>> // JVM from making those visible to Java code.
>>
>> Ironically this comment appears in the linux and bsd versions but not
>> the Solaris one! Further it is incorrect - the JLS/JVMS does not
>> prevent spurious wakeups from being made visible to Java code. That
>> has always been the intent but it took until Java 5 before we got the
>> specification for Object.wait updated to make it clear.
>>
>> So really this is all legacy crud that should be removed along with
>> the other planned cleanups (ie removing the safe_cond_* functions and
>> WorkAroundNPTLTimedWaitHang) and the os_posix refactoring.
>>
>> ---
>>
>> Sorry to mess up your "starter" bug.
>>
>> David
>>
>>
>>> product(intx, NativeMonitorTimeout, -1,
>>> "(Unstable)") \
>>> \
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044339
>>>
>
From tobias.hartmann at oracle.com Mon Jun 2 06:04:02 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 02 Jun 2014 08:04:02 +0200
Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with:
MT-unsafe modification of inline cache
In-Reply-To: <5385BF06.5090808@oracle.com>
References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com>
<5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com>
<5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com>
Message-ID: <538C13D2.5000400@oracle.com>
On 28.05.2014 12:48, Vladimir Ivanov wrote:
> Looks good.
>
> It should be safe to sync on MTF instance since it's not accessible
> outside (MTF and MT.form() are package-private).
>
> Best regards,
> Vladimir Ivanov
Thank you, Vladimir.
Could someone please push the patch?
Thanks,
Tobias
>
> On 5/28/14 1:49 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> thanks everyone for the feedback!
>>
>> @Remi: I agree with Paul. This is not a problem because if the normal
>> read sees an outdated null value, a new LambdaForm is created and
>> setCachedLambdaForm(...) is executed. This will guarantee that the
>> non-null value is seen and used. The unnecessary creation of a new
>> LamdaForm is not a problem either.
>>
>> @John: I added the code that you suggested to simulate CAS. Please find
>> the new webrev at:
>>
>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/
>>
>> Sorry for the delay, I was on vacation.
>>
>> Thanks,
>> Tobias
>>
>> On 19.05.2014 20:31, John Rose wrote:
>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann
>>> <tobias.hartmann at oracle.com> wrote:
>>>
>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>>> Yes, that is how I see it. The fast path is a racy non-volatile read
>>> of a safely-published structure.
>>>
>>> (If safe publication via arrays were broken, java.lang.String would be
>>> broken. But the JMM is carefully designed to support safe publication
>>> of array elements, and through array elements.)
>>>
>>> ? John
>>
From mikael.gerdin at oracle.com Mon Jun 2 07:28:07 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 02 Jun 2014 09:28:07 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <E17E14AC-1A46-4440-AB47-4FCDDE2E542B@oracle.com>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
<1563822.vJaocFZGNS@mgerdin03>
<E17E14AC-1A46-4440-AB47-4FCDDE2E542B@oracle.com>
Message-ID: <1874619.IXY6Wg7UoO@mgerdin03>
On Friday 30 May 2014 11.40.54 Staffan Larsen wrote:
> On 30 maj 2014, at 10:49, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> > Hi Staffan,
> >
> > On Wednesday 28 May 2014 16.50.28 Staffan Larsen wrote:
> >> This change adds a new Diagnostic Command to list all ClassLoaders and
> >> some
> >> statistics for each classloader. The command is called
> >> ?GC.classloader_stats? and the information listed is:
> >>
> >> * An id for the ClassLoader. This is the pointer to the Klass of the
> >> ClassLoader. The reason for using the Klass* (instead of the oop) is that
> >> it is stable across invocations. * The id of the ClassLoader?s parent
> >> ClassLoader.
> >> * The pointer to the ClassLoaderData structure in the VM. This can be
> >> useful for debugging. * The number of classes loaded by the ClassLoader.
> >> * The total size of all allocated metaspace chunks for the ClassLoader.
> >> * The total size of all allocated metaspace blocks for the ClassLoader.
> >>
> >> If there are anonymous classes (invokedynamic classes) attributed to the
> >> ClassLoader, the following additional information is listed: * The number
> >> of anonymous classes loaded by the ClassLoader.
> >> * The total size of all allocated metaspace chunks for anonymous classes
> >> in
> >> the ClassLoader. * The total size of all allocated metaspace blocks for
> >> anonymous classes in the ClassLoader.
> >>
> >> The information is gathered during a safe point to guarantee that the
> >> data
> >> structures are consistent.
> >>
> >> I have added a small test and have run this through jprt. A CCC request
> >> has
> >> been filed.
> >>
> >> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
> >> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
> >
> > I'm going to leave the naming of the anonymous classes and dig into the
> > code a bit:
> >
> > in classLoaderStats.hpp:
> >
> > Use the (at runtime) known object alignment?
> > 105 return hash ^ (hash >> 3); // just in case we're dealing with
> > aligned ptrs
>
> I just copied code from resourceHash.hpp? What would you suggest?
oops can have a larger alignment than 3, since you know that you will always
have oops as the hash key, why not use that knowledge and shift them down the
appropriate amount?
>
> > The &-operator is not needed here:
> > 108 typedef ResourceHashtable<oop, ClassLoaderStats*,
> > 109 &ClassLoaderStatsClosure::oop_hash,
> > &ClassLoaderStatsClosure::oop_equals> StatsTable;
>
> Removed.
>
> > do_entry does not need to be virtual since the template instantiation
> > binds to the symbol during compilation
> > 129 virtual bool do_entry(oop const& key, ClassLoaderStats* const& cls);
>
> I want to override it in a closed source class, so I?ll keep it as virtual.
Ok.
>
> > in classLoaderStats.cpp:
> >
> > Every time you encounter a CLD which reports a ClassLoader oop you will
> > overwrite the _cld field of the ClassLoaderStats.
> >
> > 59 cls->_cld = cld;
> >
> > I'm not sure if this was your intention or not, but you are relying on the
> > subtle fact that since CLD:s are prepended to the linked list in CLDG the
> > _cld field will end up pointing to the ClassLoader's CLD instead of any
> > of the anonymous classes which also hash to the same ClassLoder oop but
> > have different CLDs.
>
> Good catch. The code should be:
>
> if (!cld->is_anonymous()) {
> cls->_cld = cld;
> }
>
> > Can you convert this to an if()-block or add parenthesis for clarity?
> >
> > 60 cls->_classloader = cl == NULL ? NULL : cl->klass();
>
> Added parenthesis.
Thanks.
>
> > The ResourceMark here is unnecessary, all the resource allocations done by
> > the ClassLoaderStats-classes are done by the VMThread and are in the
> > scope of a ResourceMark covering the call to VM_Operation::doit()
> > 165 ResourceMark rm;
>
> I wasn?t aware that doit() was already covered. Removed.
>
> > in ClassLoaderStatsTest.java:
> > There is at least one other variant of "DummyClassLoader" in the
> > testlibrary, can you see if any of them are reusable?
>
> I could not find one that did what I wanted. Which one are you referring to?
I was thinking about
test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java
or, perhaps to a lesser extent
test/runtime/testlibrary/ClassUnloadCommon.java
It just seems like creating a class loader in order to load a specific class
is something that is not entirely uncommon in our testing. If you don't see a
good opportunity for making this into a reusable component for other tests
then that's fine too.
>
> I also changed the name of the diagnostic command from
> ?GC.classloader_stats? to ?VM.classloader_stats? and the output of
> anonymous classes to "+ unsafe anonymous classes?.
Ok.
>
> new webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.01/
Looks good.
/Mikael
>
> Thanks,
> /Staffan
>
> > /Mikael
> >
> >> Example output:
> >>
> >> ClassLoader Parent CLData* Classes
> >> ChunkSz>>
> >> BlockSz Type 0x00000007c002d908 0x0000000000000000 0x0000000000000000
> >>
> >> 0 0 0 sun.misc.Launcher$ExtClassLoader
> >>
> >> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761
> >> 4694016 4241312 <boot classloader> 37 75776 50928 +
> >> invokedynamic classes 0x00000007c0061028 0x00000007c0036878
> >> 0x00007fb239c2de60 1 6144 1976
> >> ClassLoaderStatsTest$DummyClassLoader 1 2048 1288 +
> >> invokedynamic classes 0x00000007c0036878 0x00000007c002d908
> >> 0x00007fb239e10fc0 8 88064 31544
> >> sun.misc.Launcher$AppClassLoader Total = 4
> >>
> >> 808 4866048 4327048 ChunkSz: Total size of all
> >>
> >> allocated metaspace chunks
> >> BlockSz: Total size of all allocated metaspace blocks (each chunk has
> >> several blocks)
> >>
> >>
> >> Thanks,
> >> /Staffan
From roland.westrelin at oracle.com Mon Jun 2 08:09:40 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 2 Jun 2014 10:09:40 +0200
Subject: [8u20] RFR (S) 8043354: OptimizePtrCompare too aggressive when
allocations are present
In-Reply-To: <5388DD73.20806@oracle.com>
References: <5388DD73.20806@oracle.com>
Message-ID: <E6F55DB3-D842-4DE0-AB73-1D0004998725@oracle.com>
Looks good to me.
Roland.
On May 30, 2014, at 9:35 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 8u20 backport request. The fix was pushed into jdk9 week ago and nightly testing shows no problems.
>
> Changes from jdk9 applied to 8u without conflicts.
>
> http://cr.openjdk.java.net/~rasbold/8043354/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8043354
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/729d5480f7db
>
> Thanks,
> Vladimir
From lev.priima at oracle.com Mon Jun 2 09:22:31 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Mon, 02 Jun 2014 13:22:31 +0400
Subject: [9] RFR (XS) 8044339: wrong comment for FilterSpuriousWakeups
option
In-Reply-To: <538BF2C8.3010102@oracle.com>
References: <53877D90.7090105@oracle.com> <53881F1B.4090805@oracle.com>
<5388AA5C.2060207@oracle.com> <538BF2C8.3010102@oracle.com>
Message-ID: <538C4257.2030609@oracle.com>
Thanks, please review update:
http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.02/
Lev
On 06/02/2014 07:43 AM, David Holmes wrote:
> Hi Lev,
>
> On 31/05/2014 1:57 AM, Lev Priima wrote:
>> Thanks for comments, please look at update:
>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.01/
>
> Please generalize the CR summary and description if you are going to
> pursue all these changes. But include additional information to
> clarify why you made the changes in the os_XXX.cpp files please. On
> that note can you please change:
>
> ! // We must filter out spurious wakeups.
>
> to
>
> ! // We ignore spurious OS wakeups unless FilterSpuriousWakeups is
> false
>
> In globals.hpp: Note that CompilerThreadHintNoPreempt and
> VMThreadHintNoPreempt are actually only meaningful on Solaris. They
> guard the call to os::hint_no_preempt which is a no-op except on
> Solaris. So those changes should be reverted.
>
> Thanks,
> David
>
>> Lev
>>
>> On 05/30/2014 10:03 AM, David Holmes wrote:
>>> Hi Lev,
>>>
>>> On 30/05/2014 4:33 AM, Lev Priima wrote:
>>>> Please review and help me with integration:
>>>>
>>>> diff -r 102506d9d873 src/share/vm/runtime/globals.hpp
>>>> --- a/src/share/vm/runtime/globals.hpp Wed May 28 14:42:00 2014
>>>> +0400
>>>> +++ b/src/share/vm/runtime/globals.hpp Thu May 29 22:29:37 2014
>>>> +0400
>>>> @@ -1144,7 +1144,7 @@
>>>> \
>>>> product(bool, FilterSpuriousWakeups,
>>>> true, \
>>>> "Prevent spurious or premature wakeups from object.wait
>>>> " \
>>>> - "(Solaris
>>>> only)") \
>>>> + "(Ignored for
>>>> Windows)") \
>>>> \
>>>
>>> Sorry to make life complicated but as I put in the bug report:
>>>
>>> The "Solaris" part dates from the days when Solaris meant "not
>>> Windows". :)
>>>
>>> A bigger problem here is that the main part of the description:
>>>
>>> "Prevent spurious or premature wakeups from object.wait "
>>>
>>> may not match what people expect - it depends on whether "filter"
>>> means to remove the item being filtered, or to keep only the item
>>> being filtered. It would clearer if it read "When true prevents ..."
>>> but even then it is not accurate as this only excludes spurious
>>> wakeups from the OS pthread_cond[timed]wait implementation - the JVM
>>> can still induce its own "spurious wakeups". So the better description
>>> would be:
>>>
>>> "When true prevents OS-level spurious, or premature, wakeups from
>>> Object.wait"
>>>
>>> But it should also be noted that where this flag is checked there is
>>> an even more inaccurate comment:
>>>
>>> // The underlying Solaris implementation, cond_timedwait, admits
>>> // spurious/premature wakeups, but the JLS/JVM spec prevents the
>>> // JVM from making those visible to Java code.
>>>
>>> Ironically this comment appears in the linux and bsd versions but not
>>> the Solaris one! Further it is incorrect - the JLS/JVMS does not
>>> prevent spurious wakeups from being made visible to Java code. That
>>> has always been the intent but it took until Java 5 before we got the
>>> specification for Object.wait updated to make it clear.
>>>
>>> So really this is all legacy crud that should be removed along with
>>> the other planned cleanups (ie removing the safe_cond_* functions and
>>> WorkAroundNPTLTimedWaitHang) and the os_posix refactoring.
>>>
>>> ---
>>>
>>> Sorry to mess up your "starter" bug.
>>>
>>> David
>>>
>>>
>>>> product(intx, NativeMonitorTimeout, -1,
>>>> "(Unstable)") \
>>>> \
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044339
>>>>
>>
From vitalyd at gmail.com Mon Jun 2 12:22:16 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 2 Jun 2014 08:22:16 -0400
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <CAHjP37FL_R0LUF2+TAVGBmSr+CLxZ9qJFo+htDAM38dicjodLQ@mail.gmail.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
<E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>
<5387D545.9080404@oracle.com>
<CAHjP37EcnirJ1LoiG0UeLzOTi0uatgb--acFOJowOfGT-FMvdA@mail.gmail.com>
<5388923B.1000608@oracle.com>
<CAHjP37FL_R0LUF2+TAVGBmSr+CLxZ9qJFo+htDAM38dicjodLQ@mail.gmail.com>
Message-ID: <CAHjP37Ednuv3tR3GQRt_pr9-H-YFK3nwDoZ5WytZEj31fFMSTg@mail.gmail.com>
Quick bump in case anyone else has any insight/suggestions.
Thanks
Sent from my phone
On May 30, 2014 11:04 AM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
> Hi Dan,
>
> Thanks for the pointer. Here's the relevant line:
>
> Java HotSpot(TM) 64-Bit Server VM warning: INFO:
> os::commit_memory(0x00002b091869c000, 65536, 1) failed; error='Cannot
> allocate memory' (errno=12)
>
> So it confirms the fixed address at which it's trying to commit and the
> 65kb size. The address matches the end of the currently committed code
> heap region, but still somewhat puzzling as to why ENOMEM is returned given
> the rest of the output in the error report. Perhaps there was a transient
> spike in mem consumption when mmap failed but the condition disappeared
> (ie. mem was free'd back to os by another process) by the time the error
> reporter pulled mem stats from the kernel?
>
> Thanks
>
>
> On Fri, May 30, 2014 at 10:14 AM, Daniel D. Daugherty <
> daniel.daugherty at oracle.com> wrote:
>
>> When 'os::commit_memory()' fails, there should be a message like the
>> following in stderr for the Java process:
>>
>> Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0xfffffd7fe8c00000,
>> 2097152, 1) failed; error='Resource temporarily unavailable' (errno=11)
>>
>> The address and size should match what you see in the stack trace
>> which provides confirmation that we have the right mesg, but the
>> important piece is the errno value...
>>
>> Dan
>>
>>
>>
>> On 5/29/14 7:20 PM, Vitaly Davidovich wrote:
>>
>>> Yes, swap and overcommit are turned off. But, there's substantial free
>>> physical memory available and looks like 65kb available to expand the
>>> code
>>> heap contiguoisly. So I'm a bit puzzled ...
>>>
>>> Taking Chris' suggestion and cc'ing hotspot dev ...
>>>
>>> Sent from my phone
>>> On May 29, 2014 8:47 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com>
>>> wrote:
>>>
>>> Could be because there is no swap on this machine:
>>>>
>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>
>>>> Vladimir
>>>>
>>>> On 5/29/14 5:35 PM, Christian Thalinger wrote:
>>>>
>>>> Although it?s the code cache I assume runtime folk would know more
>>>>> about
>>>>> this. Maybe send to hotspot-dev.
>>>>>
>>>>> On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com
>>>>> <mailto:vitalyd at gmail.com>> wrote:
>>>>>
>>>>> Hi guys,
>>>>>
>>>>>> Need a bit of help explaining a hotspot malloc failure crash on 7u51.
>>>>>> I'm going to paste the relevant snippets from the hs_err log.
>>>>>>
>>>>>> #
>>>>>> # There is insufficient memory for the Java Runtime Environment to
>>>>>> continue.
>>>>>> # Native memory allocation (malloc) failed to allocate 65536 bytes for
>>>>>> committing reserved memory.
>>>>>> # Possible reasons:
>>>>>> # The system is out of physical RAM or swap space
>>>>>> # In 32 bit mode, the process size limit was hit
>>>>>> # Possible solutions:
>>>>>> # Reduce memory load on the system
>>>>>> # Increase physical memory or swap space
>>>>>> # Check if swap backing store is full
>>>>>> # Use 64 bit Java on a 64 bit OS
>>>>>> # Decrease Java heap size (-Xmx/-Xms)
>>>>>> # Decrease number of Java threads
>>>>>> # Decrease Java thread stack sizes (-Xss)
>>>>>> # Set larger code cache with -XX:ReservedCodeCacheSize=
>>>>>> # This output file may be truncated or incomplete.
>>>>>> #
>>>>>> # Out of Memory Error (os_linux.cpp:2726), pid=10643,
>>>>>> tid=47319048501520
>>>>>> #
>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
>>>>>> 1.7.0_51-b13)
>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
>>>>>> linux-amd64 compressed oops)
>>>>>>
>>>>>>
>>>>>> --------------- T H R E A D ---------------
>>>>>>
>>>>>> Current thread (0x0000000000716800): JavaThread "C2 CompilerThread0"
>>>>>> daemon [_thread_in_vm, id=10689,
>>>>>> stack(0x00002b095303b000,0x00002b095313c000)]
>>>>>>
>>>>>> Stack: [0x00002b095303b000,0x00002b095313c000],
>>>>>> sp=0x00002b0953138d20, free space=1015k
>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>> C=native code)
>>>>>> V [libjvm.so+0x992f4a] VMError::report_and_die()+0x2ea
>>>>>> V [libjvm.so+0x4931ab] report_vm_out_of_memory(char const*, int,
>>>>>> unsigned long, char const*)+0x9b
>>>>>> V [libjvm.so+0x81338e] os::Linux::commit_memory_impl(char*,
>>>>>> unsigned
>>>>>> long, bool)+0xfe
>>>>>> V [libjvm.so+0x81383f] os::Linux::commit_memory_impl(char*,
>>>>>> unsigned
>>>>>> long, unsigned long, bool)+0x4f
>>>>>> V [libjvm.so+0x813a2c] os::pd_commit_memory(char*, unsigned long,
>>>>>> unsigned long, bool)+0xc
>>>>>> V [libjvm.so+0x80daea] os::commit_memory(char*, unsigned long,
>>>>>> unsigned long, bool)+0x2a
>>>>>> V [libjvm.so+0x98e849] VirtualSpace::expand_by(unsigned long,
>>>>>> bool)+0x1c9
>>>>>> V [libjvm.so+0x58a62c] CodeHeap::expand_by(unsigned long)+0x8c
>>>>>> V [libjvm.so+0x42111d] CodeCache::allocate(int)+0x4d
>>>>>> V [libjvm.so+0x7e1a39] nmethod::new_nmethod(methodHandle, int, int,
>>>>>> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>>>>>> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>>>>>> ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
>>>>>> V [libjvm.so+0x3cfc54] ciEnv::register_method(ciMethod*, int,
>>>>>> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
>>>>>> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>>>>>> int, bool, bool)+0x364
>>>>>> V [libjvm.so+0x4458fb] Compile::Compile(ciEnv*, C2Compiler*,
>>>>>> ciMethod*, int, bool, bool)+0x11cb
>>>>>> V [libjvm.so+0x3afa76] C2Compiler::compile_method(ciEnv*,
>>>>>> ciMethod*,
>>>>>> int)+0x176
>>>>>> V [libjvm.so+0x44ba9e]
>>>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
>>>>>> V [libjvm.so+0x44c87d] CompileBroker::compiler_thread_loop()+0x43d
>>>>>> V [libjvm.so+0x94d5ff] JavaThread::thread_main_inner()+0xdf
>>>>>> V [libjvm.so+0x94d705] JavaThread::run()+0xf5
>>>>>> V [libjvm.so+0x815538] java_start(Thread*)+0x108
>>>>>>
>>>>>> Code Cache [0x00002b091755c000, 0x00002b091869c000,
>>>>>> 0x00002b091a55c000)
>>>>>> total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb
>>>>>> largest_free_block=32247296
>>>>>>
>>>>>> Memory mappings around the code cache virtual space (bolded line is
>>>>>> the code cache segment, I believe, based on the Code Cache output
>>>>>> above):
>>>>>>
>>>>>> *2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
>>>>>> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
>>>>>> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
>>>>>> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
>>>>>> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
>>>>>> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
>>>>>> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
>>>>>> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
>>>>>>
>>>>>> /proc/meminfo:
>>>>>> MemTotal: 49521668 kB
>>>>>> MemFree: 5596796 kB
>>>>>> Buffers: 294684 kB
>>>>>> Cached: 34205856 kB
>>>>>> SwapCached: 0 kB
>>>>>> Active: 12745128 kB
>>>>>> Inactive: 28516788 kB
>>>>>> Active(anon): 9280636 kB
>>>>>> Inactive(anon): 3090264 kB
>>>>>> Active(file): 3464492 kB
>>>>>> Inactive(file): 25426524 kB
>>>>>> Unevictable: 14420 kB
>>>>>> Mlocked: 14420 kB
>>>>>> SwapTotal: 0 kB
>>>>>> SwapFree: 0 kB
>>>>>> Dirty: 20392 kB
>>>>>> Writeback: 0 kB
>>>>>> AnonPages: 6776540 kB
>>>>>> Mapped: 6292204 kB
>>>>>> Shmem: 5604620 kB
>>>>>> Slab: 1828656 kB
>>>>>> SReclaimable: 1567928 kB
>>>>>> SUnreclaim: 260728 kB
>>>>>> KernelStack: 4648 kB
>>>>>> PageTables: 58800 kB
>>>>>> NFS_Unstable: 0 kB
>>>>>> Bounce: 0 kB
>>>>>> WritebackTmp: 0 kB
>>>>>> CommitLimit: 47045584 kB
>>>>>> Committed_AS: 46046480 kB
>>>>>> VmallocTotal: 34359738367 kB
>>>>>> VmallocUsed: 460188 kB
>>>>>> VmallocChunk: 34333703480 kB
>>>>>> HugePages_Total: 0
>>>>>> HugePages_Free: 0
>>>>>> HugePages_Rsvd: 0
>>>>>> HugePages_Surp: 0
>>>>>> Hugepagesize: 2048 kB
>>>>>> DirectMap4k: 8192 kB
>>>>>> DirectMap2M: 2080768 kB
>>>>>> DirectMap1G: 48234496 kB
>>>>>>
>>>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>>>
>>>>>> * overcommit is turned off
>>>>>>
>>>>>> So the code heap was attempting to expand by 65kb at a fixed address.
>>>>>> There appears to be a 65kb mapping available between the end of the
>>>>>> current code heap mapping (2b091755c000-2b091869c000) and the next one
>>>>>> (2b09186ac000-2b091d66f000). There's about 30mb of free space left
>>>>>> (reserved, but uncommitted I take it) in the virtual space, so it's a
>>>>>> bit puzzling given there's ample physical mem available. Only thing I
>>>>>> can think of is expansion fails because it cannot get contiguous
>>>>>> space, but then I can't reconcile that with the mem mapping above.
>>>>>>
>>>>>> Does anyone have any ideas?
>>>>>>
>>>>>> Let me know if you need additional info from the hs_err file.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>
>>
>
From vladimir.x.ivanov at oracle.com Mon Jun 2 13:29:07 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 02 Jun 2014 17:29:07 +0400
Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with:
MT-unsafe modification of inline cache
In-Reply-To: <538C13D2.5000400@oracle.com>
References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com>
<5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com>
<5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com>
<538C13D2.5000400@oracle.com>
Message-ID: <538C7C23.90901@oracle.com>
Tobias, I'll take care of it.
Best regards,
Vladimir Ivanov
On 6/2/14 10:04 AM, Tobias Hartmann wrote:
>
> On 28.05.2014 12:48, Vladimir Ivanov wrote:
>> Looks good.
>>
>> It should be safe to sync on MTF instance since it's not accessible
>> outside (MTF and MT.form() are package-private).
>>
>> Best regards,
>> Vladimir Ivanov
>
> Thank you, Vladimir.
>
> Could someone please push the patch?
>
> Thanks,
> Tobias
>
>>
>> On 5/28/14 1:49 PM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> thanks everyone for the feedback!
>>>
>>> @Remi: I agree with Paul. This is not a problem because if the normal
>>> read sees an outdated null value, a new LambdaForm is created and
>>> setCachedLambdaForm(...) is executed. This will guarantee that the
>>> non-null value is seen and used. The unnecessary creation of a new
>>> LamdaForm is not a problem either.
>>>
>>> @John: I added the code that you suggested to simulate CAS. Please find
>>> the new webrev at:
>>>
>>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/
>>>
>>> Sorry for the delay, I was on vacation.
>>>
>>> Thanks,
>>> Tobias
>>>
>>> On 19.05.2014 20:31, John Rose wrote:
>>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann
>>>> <tobias.hartmann at oracle.com> wrote:
>>>>
>>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>>>> Yes, that is how I see it. The fast path is a racy non-volatile read
>>>> of a safely-published structure.
>>>>
>>>> (If safe publication via arrays were broken, java.lang.String would be
>>>> broken. But the JMM is carefully designed to support safe publication
>>>> of array elements, and through array elements.)
>>>>
>>>> ? John
>>>
>
From stefan.karlsson at oracle.com Mon Jun 2 14:03:11 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 02 Jun 2014 16:03:11 +0200
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <CAHjP37FL_R0LUF2+TAVGBmSr+CLxZ9qJFo+htDAM38dicjodLQ@mail.gmail.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com> <E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com> <5387D545.9080404@oracle.com> <CAHjP37EcnirJ1LoiG0UeLzOTi0uatgb--acFOJowOfGT-FMvdA@mail.gmail.com> <5388923B.1000608@oracle.com>
<CAHjP37FL_R0LUF2+TAVGBmSr+CLxZ9qJFo+htDAM38dicjodLQ@mail.gmail.com>
Message-ID: <538C841F.1060403@oracle.com>
On 2014-05-30 17:04, Vitaly Davidovich wrote:
> Hi Dan,
>
> Thanks for the pointer. Here's the relevant line:
>
> Java HotSpot(TM) 64-Bit Server VM warning: INFO:
> os::commit_memory(0x00002b091869c000, 65536, 1) failed; error='Cannot
> allocate memory' (errno=12)
>
> So it confirms the fixed address at which it's trying to commit and the
> 65kb size. The address matches the end of the currently committed code
> heap region, but still somewhat puzzling as to why ENOMEM is returned given
> the rest of the output in the error report. Perhaps there was a transient
> spike in mem consumption when mmap failed but the condition disappeared
> (ie. mem was free'd back to os by another process) by the time the error
> reporter pulled mem stats from the kernel?
man mmap says:
ENOMEM No memory is available, or the process's maximum number
of mappings would have been exceeded.
Could you have exceeded the maximum number of vma mappings?
The crash happens when we are converting reserved memory into committed
memory. Among other things, this will cause a vma split and from mmap.c:
int split_vma(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long addr, int new_below)
{
if (mm->map_count >= sysctl_max_map_count)
return -ENOMEM;
return __split_vma(mm, vma, addr, new_below);
}
This seems to be the default value:
$ sysctl vm/max_map_count
vm.max_map_count = 65530
StefanK
>
> Thanks
>
>
> On Fri, May 30, 2014 at 10:14 AM, Daniel D. Daugherty <
> daniel.daugherty at oracle.com> wrote:
>
>> When 'os::commit_memory()' fails, there should be a message like the
>> following in stderr for the Java process:
>>
>> Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0xfffffd7fe8c00000,
>> 2097152, 1) failed; error='Resource temporarily unavailable' (errno=11)
>>
>> The address and size should match what you see in the stack trace
>> which provides confirmation that we have the right mesg, but the
>> important piece is the errno value...
>>
>> Dan
>>
>>
>>
>> On 5/29/14 7:20 PM, Vitaly Davidovich wrote:
>>
>>> Yes, swap and overcommit are turned off. But, there's substantial free
>>> physical memory available and looks like 65kb available to expand the code
>>> heap contiguoisly. So I'm a bit puzzled ...
>>>
>>> Taking Chris' suggestion and cc'ing hotspot dev ...
>>>
>>> Sent from my phone
>>> On May 29, 2014 8:47 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com>
>>> wrote:
>>>
>>> Could be because there is no swap on this machine:
>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>
>>>> Vladimir
>>>>
>>>> On 5/29/14 5:35 PM, Christian Thalinger wrote:
>>>>
>>>> Although it?s the code cache I assume runtime folk would know more about
>>>>> this. Maybe send to hotspot-dev.
>>>>>
>>>>> On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com
>>>>> <mailto:vitalyd at gmail.com>> wrote:
>>>>>
>>>>> Hi guys,
>>>>>
>>>>>> Need a bit of help explaining a hotspot malloc failure crash on 7u51.
>>>>>> I'm going to paste the relevant snippets from the hs_err log.
>>>>>>
>>>>>> #
>>>>>> # There is insufficient memory for the Java Runtime Environment to
>>>>>> continue.
>>>>>> # Native memory allocation (malloc) failed to allocate 65536 bytes for
>>>>>> committing reserved memory.
>>>>>> # Possible reasons:
>>>>>> # The system is out of physical RAM or swap space
>>>>>> # In 32 bit mode, the process size limit was hit
>>>>>> # Possible solutions:
>>>>>> # Reduce memory load on the system
>>>>>> # Increase physical memory or swap space
>>>>>> # Check if swap backing store is full
>>>>>> # Use 64 bit Java on a 64 bit OS
>>>>>> # Decrease Java heap size (-Xmx/-Xms)
>>>>>> # Decrease number of Java threads
>>>>>> # Decrease Java thread stack sizes (-Xss)
>>>>>> # Set larger code cache with -XX:ReservedCodeCacheSize=
>>>>>> # This output file may be truncated or incomplete.
>>>>>> #
>>>>>> # Out of Memory Error (os_linux.cpp:2726), pid=10643,
>>>>>> tid=47319048501520
>>>>>> #
>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
>>>>>> 1.7.0_51-b13)
>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
>>>>>> linux-amd64 compressed oops)
>>>>>>
>>>>>>
>>>>>> --------------- T H R E A D ---------------
>>>>>>
>>>>>> Current thread (0x0000000000716800): JavaThread "C2 CompilerThread0"
>>>>>> daemon [_thread_in_vm, id=10689,
>>>>>> stack(0x00002b095303b000,0x00002b095313c000)]
>>>>>>
>>>>>> Stack: [0x00002b095303b000,0x00002b095313c000],
>>>>>> sp=0x00002b0953138d20, free space=1015k
>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>> C=native code)
>>>>>> V [libjvm.so+0x992f4a] VMError::report_and_die()+0x2ea
>>>>>> V [libjvm.so+0x4931ab] report_vm_out_of_memory(char const*, int,
>>>>>> unsigned long, char const*)+0x9b
>>>>>> V [libjvm.so+0x81338e] os::Linux::commit_memory_impl(char*, unsigned
>>>>>> long, bool)+0xfe
>>>>>> V [libjvm.so+0x81383f] os::Linux::commit_memory_impl(char*, unsigned
>>>>>> long, unsigned long, bool)+0x4f
>>>>>> V [libjvm.so+0x813a2c] os::pd_commit_memory(char*, unsigned long,
>>>>>> unsigned long, bool)+0xc
>>>>>> V [libjvm.so+0x80daea] os::commit_memory(char*, unsigned long,
>>>>>> unsigned long, bool)+0x2a
>>>>>> V [libjvm.so+0x98e849] VirtualSpace::expand_by(unsigned long,
>>>>>> bool)+0x1c9
>>>>>> V [libjvm.so+0x58a62c] CodeHeap::expand_by(unsigned long)+0x8c
>>>>>> V [libjvm.so+0x42111d] CodeCache::allocate(int)+0x4d
>>>>>> V [libjvm.so+0x7e1a39] nmethod::new_nmethod(methodHandle, int, int,
>>>>>> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>>>>>> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>>>>>> ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
>>>>>> V [libjvm.so+0x3cfc54] ciEnv::register_method(ciMethod*, int,
>>>>>> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
>>>>>> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>>>>>> int, bool, bool)+0x364
>>>>>> V [libjvm.so+0x4458fb] Compile::Compile(ciEnv*, C2Compiler*,
>>>>>> ciMethod*, int, bool, bool)+0x11cb
>>>>>> V [libjvm.so+0x3afa76] C2Compiler::compile_method(ciEnv*, ciMethod*,
>>>>>> int)+0x176
>>>>>> V [libjvm.so+0x44ba9e]
>>>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
>>>>>> V [libjvm.so+0x44c87d] CompileBroker::compiler_thread_loop()+0x43d
>>>>>> V [libjvm.so+0x94d5ff] JavaThread::thread_main_inner()+0xdf
>>>>>> V [libjvm.so+0x94d705] JavaThread::run()+0xf5
>>>>>> V [libjvm.so+0x815538] java_start(Thread*)+0x108
>>>>>>
>>>>>> Code Cache [0x00002b091755c000, 0x00002b091869c000,
>>>>>> 0x00002b091a55c000)
>>>>>> total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb
>>>>>> largest_free_block=32247296
>>>>>>
>>>>>> Memory mappings around the code cache virtual space (bolded line is
>>>>>> the code cache segment, I believe, based on the Code Cache output
>>>>>> above):
>>>>>>
>>>>>> *2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
>>>>>> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
>>>>>> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
>>>>>> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
>>>>>> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
>>>>>> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
>>>>>> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
>>>>>> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
>>>>>>
>>>>>> /proc/meminfo:
>>>>>> MemTotal: 49521668 kB
>>>>>> MemFree: 5596796 kB
>>>>>> Buffers: 294684 kB
>>>>>> Cached: 34205856 kB
>>>>>> SwapCached: 0 kB
>>>>>> Active: 12745128 kB
>>>>>> Inactive: 28516788 kB
>>>>>> Active(anon): 9280636 kB
>>>>>> Inactive(anon): 3090264 kB
>>>>>> Active(file): 3464492 kB
>>>>>> Inactive(file): 25426524 kB
>>>>>> Unevictable: 14420 kB
>>>>>> Mlocked: 14420 kB
>>>>>> SwapTotal: 0 kB
>>>>>> SwapFree: 0 kB
>>>>>> Dirty: 20392 kB
>>>>>> Writeback: 0 kB
>>>>>> AnonPages: 6776540 kB
>>>>>> Mapped: 6292204 kB
>>>>>> Shmem: 5604620 kB
>>>>>> Slab: 1828656 kB
>>>>>> SReclaimable: 1567928 kB
>>>>>> SUnreclaim: 260728 kB
>>>>>> KernelStack: 4648 kB
>>>>>> PageTables: 58800 kB
>>>>>> NFS_Unstable: 0 kB
>>>>>> Bounce: 0 kB
>>>>>> WritebackTmp: 0 kB
>>>>>> CommitLimit: 47045584 kB
>>>>>> Committed_AS: 46046480 kB
>>>>>> VmallocTotal: 34359738367 kB
>>>>>> VmallocUsed: 460188 kB
>>>>>> VmallocChunk: 34333703480 kB
>>>>>> HugePages_Total: 0
>>>>>> HugePages_Free: 0
>>>>>> HugePages_Rsvd: 0
>>>>>> HugePages_Surp: 0
>>>>>> Hugepagesize: 2048 kB
>>>>>> DirectMap4k: 8192 kB
>>>>>> DirectMap2M: 2080768 kB
>>>>>> DirectMap1G: 48234496 kB
>>>>>>
>>>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>>>
>>>>>> * overcommit is turned off
>>>>>>
>>>>>> So the code heap was attempting to expand by 65kb at a fixed address.
>>>>>> There appears to be a 65kb mapping available between the end of the
>>>>>> current code heap mapping (2b091755c000-2b091869c000) and the next one
>>>>>> (2b09186ac000-2b091d66f000). There's about 30mb of free space left
>>>>>> (reserved, but uncommitted I take it) in the virtual space, so it's a
>>>>>> bit puzzling given there's ample physical mem available. Only thing I
>>>>>> can think of is expansion fails because it cannot get contiguous
>>>>>> space, but then I can't reconcile that with the mem mapping above.
>>>>>>
>>>>>> Does anyone have any ideas?
>>>>>>
>>>>>> Let me know if you need additional info from the hs_err file.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>
From vladimir.kozlov at oracle.com Mon Jun 2 15:18:14 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 02 Jun 2014 08:18:14 -0700
Subject: [8u20] RFR (S) 8043354: OptimizePtrCompare too aggressive when
allocations are present
In-Reply-To: <E6F55DB3-D842-4DE0-AB73-1D0004998725@oracle.com>
References: <5388DD73.20806@oracle.com>
<E6F55DB3-D842-4DE0-AB73-1D0004998725@oracle.com>
Message-ID: <538C95B6.2000604@oracle.com>
Thank you, Roland
Vladimir
On 6/2/14 1:09 AM, Roland Westrelin wrote:
> Looks good to me.
>
> Roland.
>
>
> On May 30, 2014, at 9:35 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> 8u20 backport request. The fix was pushed into jdk9 week ago and nightly testing shows no problems.
>>
>> Changes from jdk9 applied to 8u without conflicts.
>>
>> http://cr.openjdk.java.net/~rasbold/8043354/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8043354
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/729d5480f7db
>>
>> Thanks,
>> Vladimir
>
From christian.tornqvist at oracle.com Mon Jun 2 15:18:00 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 2 Jun 2014 11:18:00 -0400
Subject: RFR (L) 8044140: [TESTBUG] Create NMT (Native Memory
Tracking) tests for NMT2
In-Reply-To: <53876C27.1070301@oracle.com>
References: <53861884.1050407@oracle.com> <53861C20.60303@oracle.com>
<53876C27.1070301@oracle.com>
Message-ID: <003501cf7e75$d7b99190$872cb4b0$@oracle.com>
Hi George,
Except for the things Zhengyu mentioned, the only thing I have is if TEST.groups should have 2014 as copyright year as well? Otherwise it looks good, thanks for doing this :)
Thanks,
Christian
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of George Triantafillou
Sent: Thursday, May 29, 2014 1:20 PM
To: hotspot-dev at openjdk.java.net
Subject: Re: RFR (L) 8044140: [TESTBUG] Create NMT (Native Memory Tracking) tests for NMT2
Hi Zhengyu,
Thanks for your comments.
On 5/28/2014 1:25 PM, Zhengyu Gu wrote:
> Hi,
>
> JcmdScale.java:
> There is no change, should not update copyright ...
Fixed.
>
> AutoshutdownNMT.java line #42
>
> 42 output.shouldContain("Unrecognized VM option
> 'AutoshutdownNMT'");
>
> Should be
>
> 42 output.shouldContain("Unrecognized VM option
> 'AutoShutdownNMT'");
>
>
> Also -XX:-AutoshutdownNMT => -XX:-AutoShutdownNMT
>
Fixed.
-George
>
> -Zhengyu
>
>
> On 5/28/2014 1:10 PM, George Triantafillou wrote:
>> Please review these new and modified tests for the redesigned Native
>> Memory Tracking (NMT) functionality (8028541: Native Memory Tracking
>> enhancement <https://bugs.openjdk.java.net/browse/JDK-8028541>). NMT
>> was redesigned internally to address scalability issues in the first
>> implementation. Existing functionality has not changed, with the
>> exception of the removal of the "-AutoshutdownNMT" flag.
>>
>> Please note that the following new stress tests are excluded with the
>> JTREG @ignore tag:
>>
>> test/runtime/NMT/MallocSiteHashOverflow.java
>> test/runtime/NMT/MallocStressTest.java
>>
>> These tests can be run by using the jtreg override option
>> "-ignore:run". The new key "@key stress" was also added to these tests.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8044140
>> Webrev:
>> http://cr.openjdk.java.net/~gtriantafill/bug_8044140/webrev.00/
>> <http://cr.openjdk.java.net/%7Egtriantafill/bug_8044140/webrev.00/>
>> Testing: JTREG to exercise the added tests
>>
>> Thank you,
>>
>> George
>
From vitalyd at gmail.com Mon Jun 2 15:26:30 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 2 Jun 2014 11:26:30 -0400
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <538C841F.1060403@oracle.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
<E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>
<5387D545.9080404@oracle.com>
<CAHjP37EcnirJ1LoiG0UeLzOTi0uatgb--acFOJowOfGT-FMvdA@mail.gmail.com>
<5388923B.1000608@oracle.com>
<CAHjP37FL_R0LUF2+TAVGBmSr+CLxZ9qJFo+htDAM38dicjodLQ@mail.gmail.com>
<538C841F.1060403@oracle.com>
Message-ID: <CAHjP37EMkyvyqjXNcXuNh+4duSMw1upBDOvjsahThJrt_7ybYA@mail.gmail.com>
Hi Stefan,
Good find. I checked, and the max map count is set to 1M, and looking at
the map output in the error file, I'm pretty sure we're not even close to
that (or 65k for that matter) :). I'll keep digging for now ...
Thanks
On Mon, Jun 2, 2014 at 10:03 AM, Stefan Karlsson <stefan.karlsson at oracle.com
> wrote:
>
> On 2014-05-30 17:04, Vitaly Davidovich wrote:
>
>> Hi Dan,
>>
>> Thanks for the pointer. Here's the relevant line:
>>
>> Java HotSpot(TM) 64-Bit Server VM warning: INFO:
>> os::commit_memory(0x00002b091869c000, 65536, 1) failed; error='Cannot
>> allocate memory' (errno=12)
>>
>> So it confirms the fixed address at which it's trying to commit and the
>> 65kb size. The address matches the end of the currently committed code
>> heap region, but still somewhat puzzling as to why ENOMEM is returned
>> given
>> the rest of the output in the error report. Perhaps there was a transient
>> spike in mem consumption when mmap failed but the condition disappeared
>> (ie. mem was free'd back to os by another process) by the time the error
>> reporter pulled mem stats from the kernel?
>>
>
> man mmap says:
>
> ENOMEM No memory is available, or the process's maximum number of
> mappings would have been exceeded.
>
>
> Could you have exceeded the maximum number of vma mappings?
>
> The crash happens when we are converting reserved memory into committed
> memory. Among other things, this will cause a vma split and from mmap.c:
>
> int split_vma(struct mm_struct *mm, struct vm_area_struct *vma,
> unsigned long addr, int new_below)
> {
> if (mm->map_count >= sysctl_max_map_count)
> return -ENOMEM;
>
> return __split_vma(mm, vma, addr, new_below);
> }
>
> This seems to be the default value:
> $ sysctl vm/max_map_count
> vm.max_map_count = 65530
>
> StefanK
>
>
>
>> Thanks
>>
>>
>> On Fri, May 30, 2014 at 10:14 AM, Daniel D. Daugherty <
>> daniel.daugherty at oracle.com> wrote:
>>
>> When 'os::commit_memory()' fails, there should be a message like the
>>> following in stderr for the Java process:
>>>
>>> Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(
>>> 0xfffffd7fe8c00000,
>>> 2097152, 1) failed; error='Resource temporarily unavailable' (errno=11)
>>>
>>> The address and size should match what you see in the stack trace
>>> which provides confirmation that we have the right mesg, but the
>>> important piece is the errno value...
>>>
>>> Dan
>>>
>>>
>>>
>>> On 5/29/14 7:20 PM, Vitaly Davidovich wrote:
>>>
>>> Yes, swap and overcommit are turned off. But, there's substantial free
>>>> physical memory available and looks like 65kb available to expand the
>>>> code
>>>> heap contiguoisly. So I'm a bit puzzled ...
>>>>
>>>> Taking Chris' suggestion and cc'ing hotspot dev ...
>>>>
>>>> Sent from my phone
>>>> On May 29, 2014 8:47 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com>
>>>> wrote:
>>>>
>>>> Could be because there is no swap on this machine:
>>>>
>>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>>
>>>>> Vladimir
>>>>>
>>>>> On 5/29/14 5:35 PM, Christian Thalinger wrote:
>>>>>
>>>>> Although it?s the code cache I assume runtime folk would know more
>>>>> about
>>>>>
>>>>>> this. Maybe send to hotspot-dev.
>>>>>>
>>>>>> On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com
>>>>>> <mailto:vitalyd at gmail.com>> wrote:
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Need a bit of help explaining a hotspot malloc failure crash on 7u51.
>>>>>>> I'm going to paste the relevant snippets from the hs_err log.
>>>>>>>
>>>>>>> #
>>>>>>> # There is insufficient memory for the Java Runtime Environment to
>>>>>>> continue.
>>>>>>> # Native memory allocation (malloc) failed to allocate 65536 bytes
>>>>>>> for
>>>>>>> committing reserved memory.
>>>>>>> # Possible reasons:
>>>>>>> # The system is out of physical RAM or swap space
>>>>>>> # In 32 bit mode, the process size limit was hit
>>>>>>> # Possible solutions:
>>>>>>> # Reduce memory load on the system
>>>>>>> # Increase physical memory or swap space
>>>>>>> # Check if swap backing store is full
>>>>>>> # Use 64 bit Java on a 64 bit OS
>>>>>>> # Decrease Java heap size (-Xmx/-Xms)
>>>>>>> # Decrease number of Java threads
>>>>>>> # Decrease Java thread stack sizes (-Xss)
>>>>>>> # Set larger code cache with -XX:ReservedCodeCacheSize=
>>>>>>> # This output file may be truncated or incomplete.
>>>>>>> #
>>>>>>> # Out of Memory Error (os_linux.cpp:2726), pid=10643,
>>>>>>> tid=47319048501520
>>>>>>> #
>>>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
>>>>>>> 1.7.0_51-b13)
>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
>>>>>>> linux-amd64 compressed oops)
>>>>>>>
>>>>>>>
>>>>>>> --------------- T H R E A D ---------------
>>>>>>>
>>>>>>> Current thread (0x0000000000716800): JavaThread "C2 CompilerThread0"
>>>>>>> daemon [_thread_in_vm, id=10689,
>>>>>>> stack(0x00002b095303b000,0x00002b095313c000)]
>>>>>>>
>>>>>>> Stack: [0x00002b095303b000,0x00002b095313c000],
>>>>>>> sp=0x00002b0953138d20, free space=1015k
>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>>> C=native code)
>>>>>>> V [libjvm.so+0x992f4a] VMError::report_and_die()+0x2ea
>>>>>>> V [libjvm.so+0x4931ab] report_vm_out_of_memory(char const*, int,
>>>>>>> unsigned long, char const*)+0x9b
>>>>>>> V [libjvm.so+0x81338e] os::Linux::commit_memory_impl(char*,
>>>>>>> unsigned
>>>>>>> long, bool)+0xfe
>>>>>>> V [libjvm.so+0x81383f] os::Linux::commit_memory_impl(char*,
>>>>>>> unsigned
>>>>>>> long, unsigned long, bool)+0x4f
>>>>>>> V [libjvm.so+0x813a2c] os::pd_commit_memory(char*, unsigned long,
>>>>>>> unsigned long, bool)+0xc
>>>>>>> V [libjvm.so+0x80daea] os::commit_memory(char*, unsigned long,
>>>>>>> unsigned long, bool)+0x2a
>>>>>>> V [libjvm.so+0x98e849] VirtualSpace::expand_by(unsigned long,
>>>>>>> bool)+0x1c9
>>>>>>> V [libjvm.so+0x58a62c] CodeHeap::expand_by(unsigned long)+0x8c
>>>>>>> V [libjvm.so+0x42111d] CodeCache::allocate(int)+0x4d
>>>>>>> V [libjvm.so+0x7e1a39] nmethod::new_nmethod(methodHandle, int,
>>>>>>> int,
>>>>>>> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>>>>>>> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>>>>>>> ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
>>>>>>> V [libjvm.so+0x3cfc54] ciEnv::register_method(ciMethod*, int,
>>>>>>> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
>>>>>>> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>>>>>>> int, bool, bool)+0x364
>>>>>>> V [libjvm.so+0x4458fb] Compile::Compile(ciEnv*, C2Compiler*,
>>>>>>> ciMethod*, int, bool, bool)+0x11cb
>>>>>>> V [libjvm.so+0x3afa76] C2Compiler::compile_method(ciEnv*,
>>>>>>> ciMethod*,
>>>>>>> int)+0x176
>>>>>>> V [libjvm.so+0x44ba9e]
>>>>>>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
>>>>>>> V [libjvm.so+0x44c87d] CompileBroker::compiler_thread_loop()+0x43d
>>>>>>> V [libjvm.so+0x94d5ff] JavaThread::thread_main_inner()+0xdf
>>>>>>> V [libjvm.so+0x94d705] JavaThread::run()+0xf5
>>>>>>> V [libjvm.so+0x815538] java_start(Thread*)+0x108
>>>>>>>
>>>>>>> Code Cache [0x00002b091755c000, 0x00002b091869c000,
>>>>>>> 0x00002b091a55c000)
>>>>>>> total_blobs=7033 nmethods=6349 adapters=634
>>>>>>> free_code_cache=31715Kb
>>>>>>> largest_free_block=32247296
>>>>>>>
>>>>>>> Memory mappings around the code cache virtual space (bolded line is
>>>>>>> the code cache segment, I believe, based on the Code Cache output
>>>>>>> above):
>>>>>>>
>>>>>>> *2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
>>>>>>> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
>>>>>>> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
>>>>>>> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
>>>>>>> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
>>>>>>> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
>>>>>>> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
>>>>>>> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
>>>>>>>
>>>>>>> /proc/meminfo:
>>>>>>> MemTotal: 49521668 kB
>>>>>>> MemFree: 5596796 kB
>>>>>>> Buffers: 294684 kB
>>>>>>> Cached: 34205856 kB
>>>>>>> SwapCached: 0 kB
>>>>>>> Active: 12745128 kB
>>>>>>> Inactive: 28516788 kB
>>>>>>> Active(anon): 9280636 kB
>>>>>>> Inactive(anon): 3090264 kB
>>>>>>> Active(file): 3464492 kB
>>>>>>> Inactive(file): 25426524 kB
>>>>>>> Unevictable: 14420 kB
>>>>>>> Mlocked: 14420 kB
>>>>>>> SwapTotal: 0 kB
>>>>>>> SwapFree: 0 kB
>>>>>>> Dirty: 20392 kB
>>>>>>> Writeback: 0 kB
>>>>>>> AnonPages: 6776540 kB
>>>>>>> Mapped: 6292204 kB
>>>>>>> Shmem: 5604620 kB
>>>>>>> Slab: 1828656 kB
>>>>>>> SReclaimable: 1567928 kB
>>>>>>> SUnreclaim: 260728 kB
>>>>>>> KernelStack: 4648 kB
>>>>>>> PageTables: 58800 kB
>>>>>>> NFS_Unstable: 0 kB
>>>>>>> Bounce: 0 kB
>>>>>>> WritebackTmp: 0 kB
>>>>>>> CommitLimit: 47045584 kB
>>>>>>> Committed_AS: 46046480 kB
>>>>>>> VmallocTotal: 34359738367 kB
>>>>>>> VmallocUsed: 460188 kB
>>>>>>> VmallocChunk: 34333703480 kB
>>>>>>> HugePages_Total: 0
>>>>>>> HugePages_Free: 0
>>>>>>> HugePages_Rsvd: 0
>>>>>>> HugePages_Surp: 0
>>>>>>> Hugepagesize: 2048 kB
>>>>>>> DirectMap4k: 8192 kB
>>>>>>> DirectMap2M: 2080768 kB
>>>>>>> DirectMap1G: 48234496 kB
>>>>>>>
>>>>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>>>>
>>>>>>> * overcommit is turned off
>>>>>>>
>>>>>>> So the code heap was attempting to expand by 65kb at a fixed address.
>>>>>>> There appears to be a 65kb mapping available between the end of
>>>>>>> the
>>>>>>> current code heap mapping (2b091755c000-2b091869c000) and the next
>>>>>>> one
>>>>>>> (2b09186ac000-2b091d66f000). There's about 30mb of free space left
>>>>>>> (reserved, but uncommitted I take it) in the virtual space, so it's a
>>>>>>> bit puzzling given there's ample physical mem available. Only thing
>>>>>>> I
>>>>>>> can think of is expansion fails because it cannot get contiguous
>>>>>>> space, but then I can't reconcile that with the mem mapping above.
>>>>>>>
>>>>>>> Does anyone have any ideas?
>>>>>>>
>>>>>>> Let me know if you need additional info from the hs_err file.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
From christian.thalinger at oracle.com Mon Jun 2 17:23:28 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 2 Jun 2014 10:23:28 -0700
Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with:
MT-unsafe modification of inline cache
In-Reply-To: <538C7C23.90901@oracle.com>
References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com>
<5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com>
<5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com>
<538C13D2.5000400@oracle.com> <538C7C23.90901@oracle.com>
Message-ID: <361D0F73-1993-494F-A000-62D729963D06@oracle.com>
On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> Tobias, I'll take care of it.
Are you also taking care of the backports?
>
> Best regards,
> Vladimir Ivanov
>
> On 6/2/14 10:04 AM, Tobias Hartmann wrote:
>>
>> On 28.05.2014 12:48, Vladimir Ivanov wrote:
>>> Looks good.
>>>
>>> It should be safe to sync on MTF instance since it's not accessible
>>> outside (MTF and MT.form() are package-private).
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>
>> Thank you, Vladimir.
>>
>> Could someone please push the patch?
>>
>> Thanks,
>> Tobias
>>
>>>
>>> On 5/28/14 1:49 PM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> thanks everyone for the feedback!
>>>>
>>>> @Remi: I agree with Paul. This is not a problem because if the normal
>>>> read sees an outdated null value, a new LambdaForm is created and
>>>> setCachedLambdaForm(...) is executed. This will guarantee that the
>>>> non-null value is seen and used. The unnecessary creation of a new
>>>> LamdaForm is not a problem either.
>>>>
>>>> @John: I added the code that you suggested to simulate CAS. Please find
>>>> the new webrev at:
>>>>
>>>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/
>>>>
>>>> Sorry for the delay, I was on vacation.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> On 19.05.2014 20:31, John Rose wrote:
>>>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann
>>>>> <tobias.hartmann at oracle.com> wrote:
>>>>>
>>>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>>>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>>>>> Yes, that is how I see it. The fast path is a racy non-volatile read
>>>>> of a safely-published structure.
>>>>>
>>>>> (If safe publication via arrays were broken, java.lang.String would be
>>>>> broken. But the JMM is carefully designed to support safe publication
>>>>> of array elements, and through array elements.)
>>>>>
>>>>> ? John
>>>>
>>
From vladimir.x.ivanov at oracle.com Mon Jun 2 17:38:21 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 02 Jun 2014 21:38:21 +0400
Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with:
MT-unsafe modification of inline cache
In-Reply-To: <361D0F73-1993-494F-A000-62D729963D06@oracle.com>
References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com>
<5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com>
<5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com>
<538C13D2.5000400@oracle.com> <538C7C23.90901@oracle.com>
<361D0F73-1993-494F-A000-62D729963D06@oracle.com>
Message-ID: <538CB68D.6050701@oracle.com>
On 6/2/14 9:23 PM, Christian Thalinger wrote:
>
> On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> Tobias, I'll take care of it.
>
> Are you also taking care of the backports?
Yes. I'll backport into 8u myself and for 7 I'll ask help from Sustaining.
Best regards,
Vladimir Ivanov
>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 6/2/14 10:04 AM, Tobias Hartmann wrote:
>>>
>>> On 28.05.2014 12:48, Vladimir Ivanov wrote:
>>>> Looks good.
>>>>
>>>> It should be safe to sync on MTF instance since it's not accessible
>>>> outside (MTF and MT.form() are package-private).
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>
>>> Thank you, Vladimir.
>>>
>>> Could someone please push the patch?
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>
>>>> On 5/28/14 1:49 PM, Tobias Hartmann wrote:
>>>>> Hi,
>>>>>
>>>>> thanks everyone for the feedback!
>>>>>
>>>>> @Remi: I agree with Paul. This is not a problem because if the normal
>>>>> read sees an outdated null value, a new LambdaForm is created and
>>>>> setCachedLambdaForm(...) is executed. This will guarantee that the
>>>>> non-null value is seen and used. The unnecessary creation of a new
>>>>> LamdaForm is not a problem either.
>>>>>
>>>>> @John: I added the code that you suggested to simulate CAS. Please find
>>>>> the new webrev at:
>>>>>
>>>>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/
>>>>>
>>>>> Sorry for the delay, I was on vacation.
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>> On 19.05.2014 20:31, John Rose wrote:
>>>>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann
>>>>>> <tobias.hartmann at oracle.com> wrote:
>>>>>>
>>>>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>>>>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>>>>>> Yes, that is how I see it. The fast path is a racy non-volatile read
>>>>>> of a safely-published structure.
>>>>>>
>>>>>> (If safe publication via arrays were broken, java.lang.String would be
>>>>>> broken. But the JMM is carefully designed to support safe publication
>>>>>> of array elements, and through array elements.)
>>>>>>
>>>>>> ? John
>>>>>
>>>
>
From mikael.vidstedt at oracle.com Mon Jun 2 19:05:04 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 02 Jun 2014 12:05:04 -0700
Subject: [8u20] RFR (S): 8043206: Fix signed vs. unsigned comparison warning
in copy_sparc.hpp
Message-ID: <538CCAE0.10201@oracle.com>
Please review this 8u20 backport request. The fix was pushed to jdk9 a
week ago and has not shown any problems.
The change from jdk9 applies to jdk8u/hs-dev without conflicts.
Webrev:
http://cr.openjdk.java.net/~mikael/webrevs/8043206-8u/webrev.00/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8043206
jdk9 change:
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/539e0059f825
Thanks,
Mikael
From zhengyu.gu at oracle.com Mon Jun 2 19:27:49 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 02 Jun 2014 15:27:49 -0400
Subject: [8u20] RFR (S): 8043206: Fix signed vs. unsigned comparison
warning in copy_sparc.hpp
In-Reply-To: <538CCAE0.10201@oracle.com>
References: <538CCAE0.10201@oracle.com>
Message-ID: <538CD035.2040204@oracle.com>
Look good.
-Zhengyu
On 6/2/2014 3:05 PM, Mikael Vidstedt wrote:
>
> Please review this 8u20 backport request. The fix was pushed to jdk9 a
> week ago and has not shown any problems.
>
> The change from jdk9 applies to jdk8u/hs-dev without conflicts.
>
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8043206-8u/webrev.00/webrev/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043206
> jdk9 change:
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/539e0059f825
>
> Thanks,
> Mikael
>
From daniel.daugherty at oracle.com Mon Jun 2 19:59:41 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 02 Jun 2014 13:59:41 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <53874908.5070805@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com>
<53874908.5070805@oracle.com>
Message-ID: <538CD7AD.6080900@oracle.com>
Greetings,
Need a sanity check review for the JDK8u-hs backport of this fix:
Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
The fix backported cleanly; JPRT is running the test right now;
Aurora Adhoc testing run will be started when JPRT is done...
Dan
On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
> One more round of review after refactoring the test based on comments
> from David H and Serguei.
>
> Here's the webrev for this round:
>
> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>
> Had to change the default sample size from 30 -> 15 in order to
> get the test to pass reliably on Solaris SPARC JPRT machines.
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>
>
> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>> Zhengyu is tied up with some other work so I've taken on this fix.
>>
>> Here's the webrev URL for the next round:
>>
>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>
>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>> The new test has been run with the fix via JPRT and passes on all
>> JPRT platforms. The new test has also been run without the fix and
>> fails on most platforms. Since the default sample size is just 30,
>> it is possible to get 30 runs in a row without failing.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>> This is a simple fix for incorrect lock state.
>>>
>>> The timing on setting thread's pending monitor can result stack
>>> trace dump reporting incorrect lock state. The solution is to check
>>> the monitor's owner, if the owner is other than the current thread,
>>> then the monitor, is or is in process of being, set the pending
>>> monitor of current thread.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>
>>
>>
>
>
From vladimir.kozlov at oracle.com Mon Jun 2 22:28:09 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 02 Jun 2014 15:28:09 -0700
Subject: [8u20] RFR (S): 8043206: Fix signed vs. unsigned comparison
warning in copy_sparc.hpp
In-Reply-To: <538CCAE0.10201@oracle.com>
References: <538CCAE0.10201@oracle.com>
Message-ID: <538CFA79.20500@oracle.com>
Good.
Vladimir
On 6/2/14 12:05 PM, Mikael Vidstedt wrote:
>
> Please review this 8u20 backport request. The fix was pushed to jdk9 a
> week ago and has not shown any problems.
>
> The change from jdk9 applies to jdk8u/hs-dev without conflicts.
>
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8043206-8u/webrev.00/webrev/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043206
> jdk9 change:
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/539e0059f825
>
> Thanks,
> Mikael
>
From mikael.vidstedt at oracle.com Mon Jun 2 22:44:54 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 02 Jun 2014 15:44:54 -0700
Subject: [8u20] RFR (S): 8043206: Fix signed vs. unsigned comparison
warning in copy_sparc.hpp
In-Reply-To: <538CFA79.20500@oracle.com>
References: <538CCAE0.10201@oracle.com> <538CFA79.20500@oracle.com>
Message-ID: <538CFE66.9040008@oracle.com>
Zhengyu/Vladimir - thanks!
Cheers,
Mikael
On 2014-06-02 15:28, Vladimir Kozlov wrote:
> Good.
>
> Vladimir
>
> On 6/2/14 12:05 PM, Mikael Vidstedt wrote:
>>
>> Please review this 8u20 backport request. The fix was pushed to jdk9 a
>> week ago and has not shown any problems.
>>
>> The change from jdk9 applies to jdk8u/hs-dev without conflicts.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mikael/webrevs/8043206-8u/webrev.00/webrev/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043206
>> jdk9 change:
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/539e0059f825
>>
>> Thanks,
>> Mikael
>>
From david.holmes at oracle.com Tue Jun 3 02:26:05 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 03 Jun 2014 12:26:05 +1000
Subject: [9] RFR (XS) 8044339: wrong comment for FilterSpuriousWakeups
option
In-Reply-To: <538C4257.2030609@oracle.com>
References: <53877D90.7090105@oracle.com> <53881F1B.4090805@oracle.com>
<5388AA5C.2060207@oracle.com> <538BF2C8.3010102@oracle.com>
<538C4257.2030609@oracle.com>
Message-ID: <538D323D.4010206@oracle.com>
Looks good to me!
You'll need a second reviewer and a sponsor.
Thanks,
David
On 2/06/2014 7:22 PM, Lev Priima wrote:
> Thanks, please review update:
> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.02/
>
> Lev
>
> On 06/02/2014 07:43 AM, David Holmes wrote:
>> Hi Lev,
>>
>> On 31/05/2014 1:57 AM, Lev Priima wrote:
>>> Thanks for comments, please look at update:
>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.01/
>>
>> Please generalize the CR summary and description if you are going to
>> pursue all these changes. But include additional information to
>> clarify why you made the changes in the os_XXX.cpp files please. On
>> that note can you please change:
>>
>> ! // We must filter out spurious wakeups.
>>
>> to
>>
>> ! // We ignore spurious OS wakeups unless FilterSpuriousWakeups is
>> false
>>
>> In globals.hpp: Note that CompilerThreadHintNoPreempt and
>> VMThreadHintNoPreempt are actually only meaningful on Solaris. They
>> guard the call to os::hint_no_preempt which is a no-op except on
>> Solaris. So those changes should be reverted.
>>
>> Thanks,
>> David
>>
>>> Lev
>>>
>>> On 05/30/2014 10:03 AM, David Holmes wrote:
>>>> Hi Lev,
>>>>
>>>> On 30/05/2014 4:33 AM, Lev Priima wrote:
>>>>> Please review and help me with integration:
>>>>>
>>>>> diff -r 102506d9d873 src/share/vm/runtime/globals.hpp
>>>>> --- a/src/share/vm/runtime/globals.hpp Wed May 28 14:42:00 2014
>>>>> +0400
>>>>> +++ b/src/share/vm/runtime/globals.hpp Thu May 29 22:29:37 2014
>>>>> +0400
>>>>> @@ -1144,7 +1144,7 @@
>>>>> \
>>>>> product(bool, FilterSpuriousWakeups,
>>>>> true, \
>>>>> "Prevent spurious or premature wakeups from object.wait
>>>>> " \
>>>>> - "(Solaris
>>>>> only)") \
>>>>> + "(Ignored for
>>>>> Windows)") \
>>>>> \
>>>>
>>>> Sorry to make life complicated but as I put in the bug report:
>>>>
>>>> The "Solaris" part dates from the days when Solaris meant "not
>>>> Windows". :)
>>>>
>>>> A bigger problem here is that the main part of the description:
>>>>
>>>> "Prevent spurious or premature wakeups from object.wait "
>>>>
>>>> may not match what people expect - it depends on whether "filter"
>>>> means to remove the item being filtered, or to keep only the item
>>>> being filtered. It would clearer if it read "When true prevents ..."
>>>> but even then it is not accurate as this only excludes spurious
>>>> wakeups from the OS pthread_cond[timed]wait implementation - the JVM
>>>> can still induce its own "spurious wakeups". So the better description
>>>> would be:
>>>>
>>>> "When true prevents OS-level spurious, or premature, wakeups from
>>>> Object.wait"
>>>>
>>>> But it should also be noted that where this flag is checked there is
>>>> an even more inaccurate comment:
>>>>
>>>> // The underlying Solaris implementation, cond_timedwait, admits
>>>> // spurious/premature wakeups, but the JLS/JVM spec prevents the
>>>> // JVM from making those visible to Java code.
>>>>
>>>> Ironically this comment appears in the linux and bsd versions but not
>>>> the Solaris one! Further it is incorrect - the JLS/JVMS does not
>>>> prevent spurious wakeups from being made visible to Java code. That
>>>> has always been the intent but it took until Java 5 before we got the
>>>> specification for Object.wait updated to make it clear.
>>>>
>>>> So really this is all legacy crud that should be removed along with
>>>> the other planned cleanups (ie removing the safe_cond_* functions and
>>>> WorkAroundNPTLTimedWaitHang) and the os_posix refactoring.
>>>>
>>>> ---
>>>>
>>>> Sorry to mess up your "starter" bug.
>>>>
>>>> David
>>>>
>>>>
>>>>> product(intx, NativeMonitorTimeout, -1,
>>>>> "(Unstable)") \
>>>>> \
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044339
>>>>>
>>>
>
From david.holmes at oracle.com Tue Jun 3 02:43:42 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 03 Jun 2014 12:43:42 +1000
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <538CD7AD.6080900@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<538CD7AD.6080900@oracle.com>
Message-ID: <538D365E.1050701@oracle.com>
Looks good to me.
Just need copyright update in TEST.groups
Thanks,
David
On 3/06/2014 5:59 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> Need a sanity check review for the JDK8u-hs backport of this fix:
>
> Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
>
> The fix backported cleanly; JPRT is running the test right now;
> Aurora Adhoc testing run will be started when JPRT is done...
>
> Dan
>
>
> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>> One more round of review after refactoring the test based on comments
>> from David H and Serguei.
>>
>> Here's the webrev for this round:
>>
>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>
>> Had to change the default sample size from 30 -> 15 in order to
>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>
>>> Here's the webrev URL for the next round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>
>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>> The new test has been run with the fix via JPRT and passes on all
>>> JPRT platforms. The new test has also been run without the fix and
>>> fails on most platforms. Since the default sample size is just 30,
>>> it is possible to get 30 runs in a row without failing.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>> This is a simple fix for incorrect lock state.
>>>>
>>>> The timing on setting thread's pending monitor can result stack
>>>> trace dump reporting incorrect lock state. The solution is to check
>>>> the monitor's owner, if the owner is other than the current thread,
>>>> then the monitor, is or is in process of being, set the pending
>>>> monitor of current thread.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>
>>>
>>>
>>
>>
>
From serguei.spitsyn at oracle.com Tue Jun 3 03:23:12 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 02 Jun 2014 20:23:12 -0700
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <538CD7AD.6080900@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<538CD7AD.6080900@oracle.com>
Message-ID: <538D3FA0.1050404@oracle.com>
Looks good.
Thanks,
Serguei
On 6/2/14 12:59 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> Need a sanity check review for the JDK8u-hs backport of this fix:
>
> Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
>
> The fix backported cleanly; JPRT is running the test right now;
> Aurora Adhoc testing run will be started when JPRT is done...
>
> Dan
>
>
> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>> One more round of review after refactoring the test based on comments
>> from David H and Serguei.
>>
>> Here's the webrev for this round:
>>
>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>
>> Had to change the default sample size from 30 -> 15 in order to
>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>
>>> Here's the webrev URL for the next round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>
>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>> The new test has been run with the fix via JPRT and passes on all
>>> JPRT platforms. The new test has also been run without the fix and
>>> fails on most platforms. Since the default sample size is just 30,
>>> it is possible to get 30 runs in a row without failing.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>> This is a simple fix for incorrect lock state.
>>>>
>>>> The timing on setting thread's pending monitor can result stack
>>>> trace dump reporting incorrect lock state. The solution is to check
>>>> the monitor's owner, if the owner is other than the current thread,
>>>> then the monitor, is or is in process of being, set the pending
>>>> monitor of current thread.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>
>>>
>>>
>>
>>
>
From tobias.hartmann at oracle.com Tue Jun 3 05:54:00 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 03 Jun 2014 07:54:00 +0200
Subject: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with:
MT-unsafe modification of inline cache
In-Reply-To: <538CB68D.6050701@oracle.com>
References: <53732FFB.7050407@oracle.com> <145fa3069c0.2761.5ce0156bc2f1864459fd77229eff3fe3@univ-mlv.fr> <53734692.6080409@oracle.com> <537349CA.1090904@oracle.com> <78DF1B85-B2FF-4C10-A721-2A565096983F@oracle.com> <53736C7B.2040303@oracle.com> <5373D0D7.40407@univ-mlv.fr> <5373D726.10008@oracle.com> <53747C93.3030508@univ-mlv.fr> <5374832F.5000800@oracle.com> <5374A0A8.1000805@oracle.com> <5374A50D.3080704@oracle.com> <19F4915C-F2E7-46EF-808E-89060BA2B5AD@oracle.com> <53750694.3080702@univ-mlv.fr> <5375AA6E.6030402@oracle.com>
<5375FD00.90603@oracle.com> <76B72B6C-B078-42F0-80DE-77DD56D92F92@oracle.com>
<5385B139.80808@oracle.com> <5385BF06.5090808@oracle.com>
<538C13D2.5000400@oracle.com> <538C7C23.90901@oracle.com>
<361D0F73-1993-494F-A000-62D729963D06@oracle.com>
<538CB68D.6050701@oracle.com>
Message-ID: <538D62F8.8020105@oracle.com>
Hi Vladimir,
On 02.06.2014 19:38, Vladimir Ivanov wrote:
> On 6/2/14 9:23 PM, Christian Thalinger wrote:
>>
>> On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov
>> <vladimir.x.ivanov at oracle.com> wrote:
>>
>>> Tobias, I'll take care of it.
>>
>> Are you also taking care of the backports?
> Yes. I'll backport into 8u myself and for 7 I'll ask help from
> Sustaining.
Thank you!
Best,
Tobias
>
> Best regards,
> Vladimir Ivanov
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 6/2/14 10:04 AM, Tobias Hartmann wrote:
>>>>
>>>> On 28.05.2014 12:48, Vladimir Ivanov wrote:
>>>>> Looks good.
>>>>>
>>>>> It should be safe to sync on MTF instance since it's not accessible
>>>>> outside (MTF and MT.form() are package-private).
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>
>>>> Thank you, Vladimir.
>>>>
>>>> Could someone please push the patch?
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>
>>>>> On 5/28/14 1:49 PM, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> thanks everyone for the feedback!
>>>>>>
>>>>>> @Remi: I agree with Paul. This is not a problem because if the
>>>>>> normal
>>>>>> read sees an outdated null value, a new LambdaForm is created and
>>>>>> setCachedLambdaForm(...) is executed. This will guarantee that the
>>>>>> non-null value is seen and used. The unnecessary creation of a new
>>>>>> LamdaForm is not a problem either.
>>>>>>
>>>>>> @John: I added the code that you suggested to simulate CAS.
>>>>>> Please find
>>>>>> the new webrev at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/
>>>>>>
>>>>>> Sorry for the delay, I was on vacation.
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>> On 19.05.2014 20:31, John Rose wrote:
>>>>>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann
>>>>>>> <tobias.hartmann at oracle.com> wrote:
>>>>>>>
>>>>>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>>>>>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>>>>>>> Yes, that is how I see it. The fast path is a racy non-volatile
>>>>>>> read
>>>>>>> of a safely-published structure.
>>>>>>>
>>>>>>> (If safe publication via arrays were broken, java.lang.String
>>>>>>> would be
>>>>>>> broken. But the JMM is carefully designed to support safe
>>>>>>> publication
>>>>>>> of array elements, and through array elements.)
>>>>>>>
>>>>>>> ? John
>>>>>>
>>>>
>>
From staffan.larsen at oracle.com Tue Jun 3 06:39:21 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 3 Jun 2014 08:39:21 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <1874619.IXY6Wg7UoO@mgerdin03>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
<1563822.vJaocFZGNS@mgerdin03>
<E17E14AC-1A46-4440-AB47-4FCDDE2E542B@oracle.com>
<1874619.IXY6Wg7UoO@mgerdin03>
Message-ID: <923D3321-3A62-4E86-BC49-B9D1F6E19B5E@oracle.com>
On 2 jun 2014, at 09:28, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> On Friday 30 May 2014 11.40.54 Staffan Larsen wrote:
>> On 30 maj 2014, at 10:49, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>>> Hi Staffan,
>>>
>>> On Wednesday 28 May 2014 16.50.28 Staffan Larsen wrote:
>>>> This change adds a new Diagnostic Command to list all ClassLoaders and
>>>> some
>>>> statistics for each classloader. The command is called
>>>> ?GC.classloader_stats? and the information listed is:
>>>>
>>>> * An id for the ClassLoader. This is the pointer to the Klass of the
>>>> ClassLoader. The reason for using the Klass* (instead of the oop) is that
>>>> it is stable across invocations. * The id of the ClassLoader?s parent
>>>> ClassLoader.
>>>> * The pointer to the ClassLoaderData structure in the VM. This can be
>>>> useful for debugging. * The number of classes loaded by the ClassLoader.
>>>> * The total size of all allocated metaspace chunks for the ClassLoader.
>>>> * The total size of all allocated metaspace blocks for the ClassLoader.
>>>>
>>>> If there are anonymous classes (invokedynamic classes) attributed to the
>>>> ClassLoader, the following additional information is listed: * The number
>>>> of anonymous classes loaded by the ClassLoader.
>>>> * The total size of all allocated metaspace chunks for anonymous classes
>>>> in
>>>> the ClassLoader. * The total size of all allocated metaspace blocks for
>>>> anonymous classes in the ClassLoader.
>>>>
>>>> The information is gathered during a safe point to guarantee that the
>>>> data
>>>> structures are consistent.
>>>>
>>>> I have added a small test and have run this through jprt. A CCC request
>>>> has
>>>> been filed.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
>>>
>>> I'm going to leave the naming of the anonymous classes and dig into the
>>> code a bit:
>>>
>>> in classLoaderStats.hpp:
>>>
>>> Use the (at runtime) known object alignment?
>>> 105 return hash ^ (hash >> 3); // just in case we're dealing with
>>> aligned ptrs
>>
>> I just copied code from resourceHash.hpp? What would you suggest?
>
> oops can have a larger alignment than 3, since you know that you will always
> have oops as the hash key, why not use that knowledge and shift them down the
> appropriate amount?
I have changed the hash function to:
103 static unsigned oop_hash(oop const& s1) {
104 unsigned hash = (unsigned)((uintptr_t)&s1);
105 return hash ^ (hash >> LogMinObjAlignment);
106 }
>
>>
>>> The &-operator is not needed here:
>>> 108 typedef ResourceHashtable<oop, ClassLoaderStats*,
>>> 109 &ClassLoaderStatsClosure::oop_hash,
>>> &ClassLoaderStatsClosure::oop_equals> StatsTable;
>>
>> Removed.
>>
>>> do_entry does not need to be virtual since the template instantiation
>>> binds to the symbol during compilation
>>> 129 virtual bool do_entry(oop const& key, ClassLoaderStats* const& cls);
>>
>> I want to override it in a closed source class, so I?ll keep it as virtual.
>
> Ok.
>
>>
>>> in classLoaderStats.cpp:
>>>
>>> Every time you encounter a CLD which reports a ClassLoader oop you will
>>> overwrite the _cld field of the ClassLoaderStats.
>>>
>>> 59 cls->_cld = cld;
>>>
>>> I'm not sure if this was your intention or not, but you are relying on the
>>> subtle fact that since CLD:s are prepended to the linked list in CLDG the
>>> _cld field will end up pointing to the ClassLoader's CLD instead of any
>>> of the anonymous classes which also hash to the same ClassLoder oop but
>>> have different CLDs.
>>
>> Good catch. The code should be:
>>
>> if (!cld->is_anonymous()) {
>> cls->_cld = cld;
>> }
>>
>>> Can you convert this to an if()-block or add parenthesis for clarity?
>>>
>>> 60 cls->_classloader = cl == NULL ? NULL : cl->klass();
>>
>> Added parenthesis.
>
> Thanks.
>
>>
>>> The ResourceMark here is unnecessary, all the resource allocations done by
>>> the ClassLoaderStats-classes are done by the VMThread and are in the
>>> scope of a ResourceMark covering the call to VM_Operation::doit()
>>> 165 ResourceMark rm;
>>
>> I wasn?t aware that doit() was already covered. Removed.
>>
>>> in ClassLoaderStatsTest.java:
>>> There is at least one other variant of "DummyClassLoader" in the
>>> testlibrary, can you see if any of them are reusable?
>>
>> I could not find one that did what I wanted. Which one are you referring to?
>
> I was thinking about
> test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java
>
> or, perhaps to a lesser extent
> test/runtime/testlibrary/ClassUnloadCommon.java
>
> It just seems like creating a class loader in order to load a specific class
> is something that is not entirely uncommon in our testing. If you don't see a
> good opportunity for making this into a reusable component for other tests
> then that's fine too.
I did not think any of those were appropriate for my use.
>
>>
>> I also changed the name of the diagnostic command from
>> ?GC.classloader_stats? to ?VM.classloader_stats? and the output of
>> anonymous classes to "+ unsafe anonymous classes?.
>
> Ok.
>
>>
>> new webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.01/
even newer: http://cr.openjdk.java.net/~sla/8044107/webrev.02/
Thanks,
/Staffan
>
> Looks good.
>
> /Mikael
>
>>
>> Thanks,
>> /Staffan
>>
>>> /Mikael
>>>
>>>> Example output:
>>>>
>>>> ClassLoader Parent CLData* Classes
>>>> ChunkSz>>
>>>> BlockSz Type 0x00000007c002d908 0x0000000000000000 0x0000000000000000
>>>>
>>>> 0 0 0 sun.misc.Launcher$ExtClassLoader
>>>>
>>>> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761
>>>> 4694016 4241312 <boot classloader> 37 75776 50928 +
>>>> invokedynamic classes 0x00000007c0061028 0x00000007c0036878
>>>> 0x00007fb239c2de60 1 6144 1976
>>>> ClassLoaderStatsTest$DummyClassLoader 1 2048 1288 +
>>>> invokedynamic classes 0x00000007c0036878 0x00000007c002d908
>>>> 0x00007fb239e10fc0 8 88064 31544
>>>> sun.misc.Launcher$AppClassLoader Total = 4
>>>>
>>>> 808 4866048 4327048 ChunkSz: Total size of all
>>>>
>>>> allocated metaspace chunks
>>>> BlockSz: Total size of all allocated metaspace blocks (each chunk has
>>>> several blocks)
>>>>
>>>>
>>>> Thanks,
>>>> /Staffan
From igor.ignatyev at oracle.com Tue Jun 3 07:56:24 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 03 Jun 2014 11:56:24 +0400
Subject: [9] RFR (XS) 8044339: wrong comment for FilterSpuriousWakeups
option
In-Reply-To: <538D323D.4010206@oracle.com>
References: <53877D90.7090105@oracle.com>
<53881F1B.4090805@oracle.com> <5388AA5C.2060207@oracle.com>
<538BF2C8.3010102@oracle.com> <538C4257.2030609@oracle.com>
<538D323D.4010206@oracle.com>
Message-ID: <538D7FA8.6020401@oracle.com>
Lev,
1. You have a typo in 'src/os/linux/vm/os_linux.cpp':
> 5541 // We We ignore spurious OS wakeups unless FilterSpuriousWakeups is false.
^
2. According to the process[1], you need to write a regression test or
add a 'noreg-*' label to the bug. I think adding 'noreg-doc' is a good
choice.
Otherwise, your changes look good to me. I'm not a Reviewer, but I doubt
that such changes require review from two Reviewers, so if there's no
objections, I'll sponsor your changes.
[1] http://openjdk.java.net/guide/changePlanning.html
Thanks
Igor
On 06/03/2014 06:26 AM, David Holmes wrote:
> Looks good to me!
>
> You'll need a second reviewer and a sponsor.
>
> Thanks,
> David
>
> On 2/06/2014 7:22 PM, Lev Priima wrote:
>> Thanks, please review update:
>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.02/
>>
>> Lev
>>
>> On 06/02/2014 07:43 AM, David Holmes wrote:
>>> Hi Lev,
>>>
>>> On 31/05/2014 1:57 AM, Lev Priima wrote:
>>>> Thanks for comments, please look at update:
>>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.01/
>>>
>>> Please generalize the CR summary and description if you are going to
>>> pursue all these changes. But include additional information to
>>> clarify why you made the changes in the os_XXX.cpp files please. On
>>> that note can you please change:
>>>
>>> ! // We must filter out spurious wakeups.
>>>
>>> to
>>>
>>> ! // We ignore spurious OS wakeups unless FilterSpuriousWakeups is
>>> false
>>>
>>> In globals.hpp: Note that CompilerThreadHintNoPreempt and
>>> VMThreadHintNoPreempt are actually only meaningful on Solaris. They
>>> guard the call to os::hint_no_preempt which is a no-op except on
>>> Solaris. So those changes should be reverted.
>>>
>>> Thanks,
>>> David
>>>
>>>> Lev
>>>>
>>>> On 05/30/2014 10:03 AM, David Holmes wrote:
>>>>> Hi Lev,
>>>>>
>>>>> On 30/05/2014 4:33 AM, Lev Priima wrote:
>>>>>> Please review and help me with integration:
>>>>>>
>>>>>> diff -r 102506d9d873 src/share/vm/runtime/globals.hpp
>>>>>> --- a/src/share/vm/runtime/globals.hpp Wed May 28 14:42:00 2014
>>>>>> +0400
>>>>>> +++ b/src/share/vm/runtime/globals.hpp Thu May 29 22:29:37 2014
>>>>>> +0400
>>>>>> @@ -1144,7 +1144,7 @@
>>>>>> \
>>>>>> product(bool, FilterSpuriousWakeups,
>>>>>> true, \
>>>>>> "Prevent spurious or premature wakeups from object.wait
>>>>>> " \
>>>>>> - "(Solaris
>>>>>> only)") \
>>>>>> + "(Ignored for
>>>>>> Windows)") \
>>>>>> \
>>>>>
>>>>> Sorry to make life complicated but as I put in the bug report:
>>>>>
>>>>> The "Solaris" part dates from the days when Solaris meant "not
>>>>> Windows". :)
>>>>>
>>>>> A bigger problem here is that the main part of the description:
>>>>>
>>>>> "Prevent spurious or premature wakeups from object.wait "
>>>>>
>>>>> may not match what people expect - it depends on whether "filter"
>>>>> means to remove the item being filtered, or to keep only the item
>>>>> being filtered. It would clearer if it read "When true prevents ..."
>>>>> but even then it is not accurate as this only excludes spurious
>>>>> wakeups from the OS pthread_cond[timed]wait implementation - the JVM
>>>>> can still induce its own "spurious wakeups". So the better description
>>>>> would be:
>>>>>
>>>>> "When true prevents OS-level spurious, or premature, wakeups from
>>>>> Object.wait"
>>>>>
>>>>> But it should also be noted that where this flag is checked there is
>>>>> an even more inaccurate comment:
>>>>>
>>>>> // The underlying Solaris implementation, cond_timedwait, admits
>>>>> // spurious/premature wakeups, but the JLS/JVM spec prevents the
>>>>> // JVM from making those visible to Java code.
>>>>>
>>>>> Ironically this comment appears in the linux and bsd versions but not
>>>>> the Solaris one! Further it is incorrect - the JLS/JVMS does not
>>>>> prevent spurious wakeups from being made visible to Java code. That
>>>>> has always been the intent but it took until Java 5 before we got the
>>>>> specification for Object.wait updated to make it clear.
>>>>>
>>>>> So really this is all legacy crud that should be removed along with
>>>>> the other planned cleanups (ie removing the safe_cond_* functions and
>>>>> WorkAroundNPTLTimedWaitHang) and the os_posix refactoring.
>>>>>
>>>>> ---
>>>>>
>>>>> Sorry to mess up your "starter" bug.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>> product(intx, NativeMonitorTimeout, -1,
>>>>>> "(Unstable)") \
>>>>>> \
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044339
>>>>>>
>>>>
>>
From stefan.karlsson at oracle.com Tue Jun 3 07:59:46 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 03 Jun 2014 09:59:46 +0200
Subject: 8042933: assert(capacity_until_gc >= committed_bytes) failed
In-Reply-To: <1502229.ArWomoX4nV@ehelin-laptop>
References: <4471789.3Gp5iV3Z2a@ehelin-desktop> <5385CF00.2070605@oracle.com>
<1502229.ArWomoX4nV@ehelin-laptop>
Message-ID: <538D8072.4080201@oracle.com>
On 2014-05-29 14:43, Erik Helin wrote:
> Hi StefanK,
>
> thanks for reviewing! Please see new patches at:
>
> Incremental: http://cr.openjdk.java.net/~ehelin/8042933/webrev.00-01/
Looks good.
StefanK
> Full: http://cr.openjdk.java.net/~ehelin/8042933/webrev.01/
>
> and comments inline.
>
> On Wednesday 28 May 2014 13:56:48 PM Stefan Karlsson wrote:
>> On 2014-05-28 13:10, Erik Helin wrote:
>>> Hi all,
>>>
>>> this is the second attemp to fix JDK-8034852 [0], but since I backed
>>> out the previous attempt, I have to use a new bug [1] (you can't use
>>> the same bug-id for two different committs).
>>>
>>> For a background to the original problem, please see the old email
>>> thread [2]. This patch is just and updated version of the original
>>> patch [3]. The issue with the original path is that
>>> MetaspaceGC::allowed_expansion can, during special circumstances,
>>> allow the Metaspace high-water mark (HWM aka
>>> MetaspaceGC::_capacity_until_GC) to become larger than the amount of
>>> committed memory. Keeping the HWM less than or equal to how much we
>>> have committed is an invariant we would like to be true in Metaspace
>>> at all times to make it easier to reason about the sizing heuristics.
>>>
>>> This patch changes MetaspaceGC::allowed_expansion to always enforce
>>> the invariant that HWM <= committed_bytes. However, we still want to
>>> allow the VM to allocate as much metadata it wants during
>>> initialization. To achieve this, we set the HWM to MaxMetaspaceSize
>>> when initializing Metaspace and then reset the HWM to
>>> max(MetaspaceSize, HWM) once the initialization is done. Thanks
>>> StefanK for coming up with this approach!
>>>
>>> MetaspaceGC::allowed_expansion previously also allowed the VM to
>>> allocate as much metadata it wants when the GC lock is active and we
>>> are awaiting a GC. The new behaviour will be to try to expand the HWM
>>> and then allocate (the expand_and_allocate call in
>>> CollectorPolicy::satisfy_failed_metadata_allocation). Under very
>>> special circumstances this might cause a thread to now await the GC in
>>> GC_locker::stall_until_clear instead of getting its metadata and
>>> continue executing.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8042933/webrev.00/
>> http://cr.openjdk.java.net/~ehelin/8042933/webrev.00/src/share/vm/memory/met
>> aspace.hpp.udiff.html
>>
>> Could you add a comment explaining why we use MaxMetaspaceSize here,
>> instead of the MetaspaceSize:
> Sure, done.
>
>> - static void initialize() { _capacity_until_GC = MetaspaceSize; }
>> + static void initialize() { _capacity_until_GC = MaxMetaspaceSize; }
>> + static void post_initialize();
>>
>> Maybe it would be better to move the implementation of initialize() to
>> metaspace.cpp and place it together with the post_initialize() function?
>> I think that would make it more apparent that we just
>> setcapacity_until_GC temporarily to MaxMetaspaceSize.
> Agree, fixed.
>
>> http://cr.openjdk.java.net/~ehelin/8042933/webrev.00/src/share/vm/runtime/th
>> read.cpp.udiff.html
>>
>> Could add a blank line between these two functions, so that they are not
>> grouped together?
> Yep, updated.
>
> Thanks,
> Erik
>
>> // Set flag that basic initialization has completed. Used by exceptions
>> and various // debug stuff, that does not work until all basic classes have
>> been initialized. set_init_completed();
>> + Metaspace::post_initialize();
>>
>> Otherwise, this looks good.
>>
>> thanks,
>> StefanK
>>
>>> Testing:
>>> - JPRT
>>>
>>> - Ad-hoc testing (on all platforms):
>>> - Kitchensink
>>> - runThese
>>> - Parallel Class Loading testlist
>>> - Metaspace testlist
>>> - GC nightly testlist
>>> - OOM testlist
>>> - Quick testlist
>>> - JTREG tests in both VM and JDK
>>>
>>> Thanks,
>>> Erik
>>>
>>> [0]: https://bugs.openjdk.java.net/browse/JDK-8034852
>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8042933
>>> [2]:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013716.html
>>> [3]: http://cr.openjdk.java.net/~ehelin/8034852/webrev.00/
From java at java4.info Tue Jun 3 08:50:36 2014
From: java at java4.info (Florian Binder)
Date: Tue, 03 Jun 2014 10:50:36 +0200
Subject: Java pepper support
Message-ID: <538D8C5C.5070205@java4.info>
Hi all,
I am not sure if this is the right list for this question. Please let me
know if there is a better one.
I am interested in the future of java applets.
Chrome is phasing out NPAPI support , probably by the end of 2014. This
means java applets wont run any more in chrome. Instead of this they
introduced a new plugin api called pepper (PPAPI).
Is there a plan to create a java pepper plugin?
For more information about the NPAPI deprecation see:
http://www.chromium.org/developers/npapi-deprecation
Thanks,
Flo
From aph at redhat.com Tue Jun 3 09:14:49 2014
From: aph at redhat.com (Andrew Haley)
Date: Tue, 03 Jun 2014 10:14:49 +0100
Subject: Java pepper support
In-Reply-To: <538D8C5C.5070205@java4.info>
References: <538D8C5C.5070205@java4.info>
Message-ID: <538D9209.1060806@redhat.com>
On 03/06/14 09:50, Florian Binder wrote:
> I am not sure if this is the right list for this question. Please let me
> know if there is a better one.
distro-pkg-dev at openjdk.java.net
> I am interested in the future of java applets.
> Chrome is phasing out NPAPI support , probably by the end of 2014. This
> means java applets wont run any more in chrome. Instead of this they
> introduced a new plugin api called pepper (PPAPI).
>
> Is there a plan to create a java pepper plugin?
We're thinking about it. Come over to distro-pkg-dev and
have a chat.
Andrew.
From stefan.karlsson at oracle.com Tue Jun 3 09:22:08 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 03 Jun 2014 11:22:08 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
Message-ID: <538D93C0.2080103@oracle.com>
Hi Staffan,
Thanks for implementing this feature!
On 2014-05-28 16:50, Staffan Larsen wrote:
> This change adds a new Diagnostic Command to list all ClassLoaders and some statistics for each classloader. The command is called ?GC.classloader_stats? and the information listed is:
>
> * An id for the ClassLoader. This is the pointer to the Klass of the ClassLoader. The reason for using the Klass* (instead of the oop) is that it is stable across invocations.
I agree that it's good to get a stable value, but IMHO the code would be
easier if you just stored the oops for _classloader and _parent instead
of the Klass*.
71 ClassLoaderData* _cld;
72 Klass* _classloader;
73 Klass* _parent;
This will work since all this is done during a safepoint.
As the code is written right now, it's awkward that we put Klass*s in
fields named _parent and _classloader. We usually put oops and CLD*s in
fields that are named that way.
The following code:
144 // It does not exist in our table - add it
145 ClassLoaderStats* cls = new ClassLoaderStats();
146 cls->_classloader = cl->klass();
147 oop parent = java_lang_ClassLoader::parent(cl);
148 if (parent != NULL) {
149 cls->_parent = parent->klass();
150 }
could be condensed down to:
144 // It does not exist in our table - add it
145 ClassLoaderStats* cls = new ClassLoaderStats();
146 cls->_classloader = cl
147 cls->_parent = java_lang_ClassLoader::parent(cl);
or even:
144 // It does not exist in our table - add it
145 ClassLoaderStats* cls = new ClassLoaderStats(cl, java_lang_ClassLoader::parent(cl));
and
63 cls->_classloader = (cl == NULL ? NULL : cl->klass());
64 if (cl != NULL) {
65 oop parent = java_lang_ClassLoader::parent(cl);
66 if (parent != NULL) {
67 cls->_parent = parent->klass();
68 addEmptyParents(parent);
69 }
70 }
would be come:
63 cls->_classloader = cl;
64 if (cl != NULL) {
65 cls->_parent = java_lang_ClassLoader::parent(cl);
68 addEmptyParents(cls->_parent);
70 }
> * The id of the ClassLoader?s parent ClassLoader.
> * The pointer to the ClassLoaderData structure in the VM. This can be useful for debugging.
> * The number of classes loaded by the ClassLoader.
> * The total size of all allocated metaspace chunks for the ClassLoader.
> * The total size of all allocated metaspace blocks for the ClassLoader.
>
> If there are anonymous classes (invokedynamic classes) attributed to the ClassLoader, the following additional information is listed:
> * The number of anonymous classes loaded by the ClassLoader.
> * The total size of all allocated metaspace chunks for anonymous classes in the ClassLoader.
> * The total size of all allocated metaspace blocks for anonymous classes in the ClassLoader.
>
> The information is gathered during a safe point to guarantee that the data structures are consistent.
>
> I have added a small test and have run this through jprt. A CCC request has been filed.
>
> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
>
> Example output:
>
> ClassLoader Parent CLData* Classes ChunkSz BlockSz Type
We usually say ClassLoaderData or CLD in the code, but never CLData.
Could this be changed to CLD* or CLD? I guess ClassLoaderData would be
too long. Erik also had a suggestion on a more user-friendly name, I'm
fine with that as well.
> 0x00000007c002d908 0x0000000000000000 0x0000000000000000 0 0 0 sun.misc.Launcher$ExtClassLoader
> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761 4694016 4241312 <boot classloader>
> 37 75776 50928 + invokedynamic classes
> 0x00000007c0061028 0x00000007c0036878 0x00007fb239c2de60 1 6144 1976 ClassLoaderStatsTest$DummyClassLoader
> 1 2048 1288 + invokedynamic classes
> 0x00000007c0036878 0x00000007c002d908 0x00007fb239e10fc0 8 88064 31544 sun.misc.Launcher$AppClassLoader
> Total = 4 808 4866048 4327048
> ChunkSz: Total size of all allocated metaspace chunks
> BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)
http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.hpp.html
Is there a reason why these are intx instead of uintx?
113 intx _total_loaders;
114 intx _total_classes;
Would you mind changing the name of _classloader to _class_loader?
69 class ClassLoaderStats : public ResourceObj {
70 public:
71 ClassLoaderData* _cld;
72 Klass* _classloader;
http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.cpp.html
There's a couple of usages of SSIZE_FORMAT_W where I think you should be
using SIZE_FORMAT_W
At some point it would be nice to have an option to be able to list the
usages of all individual anonymous class loaders.
http://cr.openjdk.java.net/~sla/8044107/webrev.02/test/serviceability/dcmd/ClassLoaderStatsTest.java.html
I don't know if this is a common style in our testing, but I often read
test code without the aid of an IDE so import statements with *s make it
harder for me to understand where imported classes come from:
31 import java.nio.*;
32 import java.nio.channels.*;
33 import java.io.*;
34 import java.util.regex.Matcher;
35 import java.util.regex.Pattern;
thanks,
StefanK
>
>
> Thanks,
> /Staffan
From mikael.gerdin at oracle.com Tue Jun 3 10:34:39 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 03 Jun 2014 12:34:39 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <923D3321-3A62-4E86-BC49-B9D1F6E19B5E@oracle.com>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
<1874619.IXY6Wg7UoO@mgerdin03>
<923D3321-3A62-4E86-BC49-B9D1F6E19B5E@oracle.com>
Message-ID: <1446856.y6itZaOnnI@mgerdin03>
On Tuesday 03 June 2014 08.39.21 Staffan Larsen wrote:
> On 2 jun 2014, at 09:28, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> > On Friday 30 May 2014 11.40.54 Staffan Larsen wrote:
> >> On 30 maj 2014, at 10:49, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> >>> Hi Staffan,
> >>>
> >>> On Wednesday 28 May 2014 16.50.28 Staffan Larsen wrote:
> >>>> This change adds a new Diagnostic Command to list all ClassLoaders and
> >>>> some
> >>>> statistics for each classloader. The command is called
> >>>> ?GC.classloader_stats? and the information listed is:
> >>>>
> >>>> * An id for the ClassLoader. This is the pointer to the Klass of the
> >>>> ClassLoader. The reason for using the Klass* (instead of the oop) is
> >>>> that
> >>>> it is stable across invocations. * The id of the ClassLoader?s parent
> >>>> ClassLoader.
> >>>> * The pointer to the ClassLoaderData structure in the VM. This can be
> >>>> useful for debugging. * The number of classes loaded by the
> >>>> ClassLoader.
> >>>> * The total size of all allocated metaspace chunks for the ClassLoader.
> >>>> * The total size of all allocated metaspace blocks for the ClassLoader.
> >>>>
> >>>> If there are anonymous classes (invokedynamic classes) attributed to
> >>>> the
> >>>> ClassLoader, the following additional information is listed: * The
> >>>> number
> >>>> of anonymous classes loaded by the ClassLoader.
> >>>> * The total size of all allocated metaspace chunks for anonymous
> >>>> classes
> >>>> in
> >>>> the ClassLoader. * The total size of all allocated metaspace blocks for
> >>>> anonymous classes in the ClassLoader.
> >>>>
> >>>> The information is gathered during a safe point to guarantee that the
> >>>> data
> >>>> structures are consistent.
> >>>>
> >>>> I have added a small test and have run this through jprt. A CCC request
> >>>> has
> >>>> been filed.
> >>>>
> >>>> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
> >>>
> >>> I'm going to leave the naming of the anonymous classes and dig into the
> >>> code a bit:
> >>>
> >>> in classLoaderStats.hpp:
> >>>
> >>> Use the (at runtime) known object alignment?
> >>> 105 return hash ^ (hash >> 3); // just in case we're dealing with
> >>> aligned ptrs
> >>
> >> I just copied code from resourceHash.hpp? What would you suggest?
> >
> > oops can have a larger alignment than 3, since you know that you will
> > always have oops as the hash key, why not use that knowledge and shift
> > them down the appropriate amount?
>
> I have changed the hash function to:
>
> 103 static unsigned oop_hash(oop const& s1) {
> 104 unsigned hash = (unsigned)((uintptr_t)&s1);
> 105 return hash ^ (hash >> LogMinObjAlignment);
> 106 }
Great!
/Mikael
>
> >>> The &-operator is not needed here:
> >>> 108 typedef ResourceHashtable<oop, ClassLoaderStats*,
> >>> 109 &ClassLoaderStatsClosure::oop_hash,
> >>> &ClassLoaderStatsClosure::oop_equals> StatsTable;
> >>
> >> Removed.
> >>
> >>> do_entry does not need to be virtual since the template instantiation
> >>> binds to the symbol during compilation
> >>> 129 virtual bool do_entry(oop const& key, ClassLoaderStats* const&
> >>> cls);
> >>
> >> I want to override it in a closed source class, so I?ll keep it as
> >> virtual.
> >
> > Ok.
> >
> >>> in classLoaderStats.cpp:
> >>>
> >>> Every time you encounter a CLD which reports a ClassLoader oop you will
> >>> overwrite the _cld field of the ClassLoaderStats.
> >>>
> >>> 59 cls->_cld = cld;
> >>>
> >>> I'm not sure if this was your intention or not, but you are relying on
> >>> the
> >>> subtle fact that since CLD:s are prepended to the linked list in CLDG
> >>> the
> >>> _cld field will end up pointing to the ClassLoader's CLD instead of any
> >>> of the anonymous classes which also hash to the same ClassLoder oop but
> >>> have different CLDs.
> >>
> >> Good catch. The code should be:
> >> if (!cld->is_anonymous()) {
> >>
> >> cls->_cld = cld;
> >>
> >> }
> >>
> >>> Can you convert this to an if()-block or add parenthesis for clarity?
> >>>
> >>> 60 cls->_classloader = cl == NULL ? NULL : cl->klass();
> >>
> >> Added parenthesis.
> >
> > Thanks.
> >
> >>> The ResourceMark here is unnecessary, all the resource allocations done
> >>> by
> >>> the ClassLoaderStats-classes are done by the VMThread and are in the
> >>> scope of a ResourceMark covering the call to VM_Operation::doit()
> >>> 165 ResourceMark rm;
> >>
> >> I wasn?t aware that doit() was already covered. Removed.
> >>
> >>> in ClassLoaderStatsTest.java:
> >>> There is at least one other variant of "DummyClassLoader" in the
> >>> testlibrary, can you see if any of them are reusable?
> >>
> >> I could not find one that did what I wanted. Which one are you referring
> >> to?>
> > I was thinking about
> > test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java
> >
> > or, perhaps to a lesser extent
> > test/runtime/testlibrary/ClassUnloadCommon.java
> >
> > It just seems like creating a class loader in order to load a specific
> > class is something that is not entirely uncommon in our testing. If you
> > don't see a good opportunity for making this into a reusable component
> > for other tests then that's fine too.
>
> I did not think any of those were appropriate for my use.
>
> >> I also changed the name of the diagnostic command from
> >> ?GC.classloader_stats? to ?VM.classloader_stats? and the output of
> >> anonymous classes to "+ unsafe anonymous classes?.
> >
> > Ok.
> >
> >> new webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.01/
>
> even newer: http://cr.openjdk.java.net/~sla/8044107/webrev.02/
>
> Thanks,
> /Staffan
>
> > Looks good.
> >
> > /Mikael
> >
> >> Thanks,
> >> /Staffan
> >>
> >>> /Mikael
> >>>
> >>>> Example output:
> >>>>
> >>>> ClassLoader Parent CLData* Classes
> >>>> ChunkSz>>
> >>>> BlockSz Type 0x00000007c002d908 0x0000000000000000
> >>>> 0x0000000000000000
> >>>>
> >>>> 0 0 0 sun.misc.Launcher$ExtClassLoader
> >>>>
> >>>> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761
> >>>> 4694016 4241312 <boot classloader> 37 75776 50928 +
> >>>> invokedynamic classes 0x00000007c0061028 0x00000007c0036878
> >>>> 0x00007fb239c2de60 1 6144 1976
> >>>> ClassLoaderStatsTest$DummyClassLoader 1 2048 1288 +
> >>>> invokedynamic classes 0x00000007c0036878 0x00000007c002d908
> >>>> 0x00007fb239e10fc0 8 88064 31544
> >>>> sun.misc.Launcher$AppClassLoader Total = 4
> >>>>
> >>>> 808 4866048 4327048 ChunkSz: Total size of all
> >>>>
> >>>> allocated metaspace chunks
> >>>> BlockSz: Total size of all allocated metaspace blocks (each chunk has
> >>>> several blocks)
> >>>>
> >>>>
> >>>> Thanks,
> >>>> /Staffan
From daniel.daugherty at oracle.com Tue Jun 3 12:39:11 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 03 Jun 2014 06:39:11 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <538D365E.1050701@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<538CD7AD.6080900@oracle.com> <538D365E.1050701@oracle.com>
Message-ID: <538DC1EF.2080705@oracle.com>
On 6/2/14 8:43 PM, David Holmes wrote:
> Looks good to me.
Thanks!
> Just need copyright update in TEST.groups
Will do.
Dan
>
> Thanks,
> David
>
> On 3/06/2014 5:59 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Need a sanity check review for the JDK8u-hs backport of this fix:
>>
>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
>>
>> The fix backported cleanly; JPRT is running the test right now;
>> Aurora Adhoc testing run will be started when JPRT is done...
>>
>> Dan
>>
>>
>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>> One more round of review after refactoring the test based on comments
>>> from David H and Serguei.
>>>
>>> Here's the webrev for this round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>
>>> Had to change the default sample size from 30 -> 15 in order to
>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>
>>>> Here's the webrev URL for the next round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>
>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>> The new test has been run with the fix via JPRT and passes on all
>>>> JPRT platforms. The new test has also been run without the fix and
>>>> fails on most platforms. Since the default sample size is just 30,
>>>> it is possible to get 30 runs in a row without failing.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>> This is a simple fix for incorrect lock state.
>>>>>
>>>>> The timing on setting thread's pending monitor can result stack
>>>>> trace dump reporting incorrect lock state. The solution is to check
>>>>> the monitor's owner, if the owner is other than the current thread,
>>>>> then the monitor, is or is in process of being, set the pending
>>>>> monitor of current thread.
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
From daniel.daugherty at oracle.com Tue Jun 3 12:39:46 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 03 Jun 2014 06:39:46 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <538D3FA0.1050404@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<538CD7AD.6080900@oracle.com> <538D3FA0.1050404@oracle.com>
Message-ID: <538DC212.6010403@oracle.com>
On 6/2/14 9:23 PM, serguei.spitsyn at oracle.com wrote:
> Looks good.
Thanks!
Dan
>
> Thanks,
> Serguei
>
>
> On 6/2/14 12:59 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Need a sanity check review for the JDK8u-hs backport of this fix:
>>
>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
>>
>> The fix backported cleanly; JPRT is running the test right now;
>> Aurora Adhoc testing run will be started when JPRT is done...
>>
>> Dan
>>
>>
>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>> One more round of review after refactoring the test based on comments
>>> from David H and Serguei.
>>>
>>> Here's the webrev for this round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>
>>> Had to change the default sample size from 30 -> 15 in order to
>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>
>>>> Here's the webrev URL for the next round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>
>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>> The new test has been run with the fix via JPRT and passes on all
>>>> JPRT platforms. The new test has also been run without the fix and
>>>> fails on most platforms. Since the default sample size is just 30,
>>>> it is possible to get 30 runs in a row without failing.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>> This is a simple fix for incorrect lock state.
>>>>>
>>>>> The timing on setting thread's pending monitor can result stack
>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>> check the monitor's owner, if the owner is other than the current
>>>>> thread, then the monitor, is or is in process of being, set the
>>>>> pending monitor of current thread.
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
From zhengyu.gu at oracle.com Tue Jun 3 13:00:57 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 03 Jun 2014 09:00:57 -0400
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <538CD7AD.6080900@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<538CD7AD.6080900@oracle.com>
Message-ID: <538DC709.5030907@oracle.com>
Look good.
-Zhengyu
On 6/2/2014 3:59 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> Need a sanity check review for the JDK8u-hs backport of this fix:
>
> Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
>
> The fix backported cleanly; JPRT is running the test right now;
> Aurora Adhoc testing run will be started when JPRT is done...
>
> Dan
>
>
> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>> One more round of review after refactoring the test based on comments
>> from David H and Serguei.
>>
>> Here's the webrev for this round:
>>
>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>
>> Had to change the default sample size from 30 -> 15 in order to
>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>
>>> Here's the webrev URL for the next round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>
>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>> The new test has been run with the fix via JPRT and passes on all
>>> JPRT platforms. The new test has also been run without the fix and
>>> fails on most platforms. Since the default sample size is just 30,
>>> it is possible to get 30 runs in a row without failing.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>> This is a simple fix for incorrect lock state.
>>>>
>>>> The timing on setting thread's pending monitor can result stack
>>>> trace dump reporting incorrect lock state. The solution is to check
>>>> the monitor's owner, if the owner is other than the current thread,
>>>> then the monitor, is or is in process of being, set the pending
>>>> monitor of current thread.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>
>>>
>>>
>>
>>
>
From staffan.larsen at oracle.com Tue Jun 3 13:11:03 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 3 Jun 2014 15:11:03 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <538D93C0.2080103@oracle.com>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
<538D93C0.2080103@oracle.com>
Message-ID: <4DA91FF1-334E-4613-BCB4-837BD8A36683@oracle.com>
Stefan, thanks for the comments. See below.
On 3 jun 2014, at 11:22, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> Hi Staffan,
>
> Thanks for implementing this feature!
>
> On 2014-05-28 16:50, Staffan Larsen wrote:
>> This change adds a new Diagnostic Command to list all ClassLoaders and some statistics for each classloader. The command is called ?GC.classloader_stats? and the information listed is:
>>
>> * An id for the ClassLoader. This is the pointer to the Klass of the ClassLoader. The reason for using the Klass* (instead of the oop) is that it is stable across invocations.
>
> I agree that it's good to get a stable value, but IMHO the code would be easier if you just stored the oops for _classloader and _parent instead of the Klass*.
>
> 71 ClassLoaderData* _cld;
> 72 Klass* _classloader;
> 73 Klass* _parent;
>
>
> This will work since all this is done during a safe point.
The reason I choose Klass* was that I wanted something that was stable /across/ invocations, not just during one invocation of the Diagnostic Command. That way you can compare the output over time.
> As the code is written right now, it's awkward that we put Klass*s in fields named _parent and _classloader. We usually put oops and CLD*s in fields that are named that way.
I can change the names of the fields. Suggestions?
>
> The following code:
>
> 144 // It does not exist in our table - add it
> 145 ClassLoaderStats* cls = new ClassLoaderStats();
> 146 cls->_classloader = cl->klass();
> 147 oop parent = java_lang_ClassLoader::parent(cl);
> 148 if (parent != NULL) {
> 149 cls->_parent = parent->klass();
> 150 }
>
> could be condensed down to:
>
> 144 // It does not exist in our table - add it
> 145 ClassLoaderStats* cls = new ClassLoaderStats();
> 146 cls->_classloader = cl
> 147 cls->_parent = java_lang_ClassLoader::parent(cl);
>
> or even:
>
> 144 // It does not exist in our table - add it
> 145 ClassLoaderStats* cls = new ClassLoaderStats(cl, java_lang_ClassLoader::parent(cl));
>
>
> and
>
> 63 cls->_classloader = (cl == NULL ? NULL : cl->klass());
> 64 if (cl != NULL) {
> 65 oop parent = java_lang_ClassLoader::parent(cl);
> 66 if (parent != NULL) {
> 67 cls->_parent = parent->klass();
> 68 addEmptyParents(parent);
> 69 }
> 70 }
>
> would be come:
>
> 63 cls->_classloader = cl;
> 64 if (cl != NULL) {
> 65 cls->_parent = java_lang_ClassLoader::parent(cl);
> 68 addEmptyParents(cls->_parent);
> 70 }
>
>
>> * The id of the ClassLoader?s parent ClassLoader.
>> * The pointer to the ClassLoaderData structure in the VM. This can be useful for debugging.
>> * The number of classes loaded by the ClassLoader.
>> * The total size of all allocated metaspace chunks for the ClassLoader.
>> * The total size of all allocated metaspace blocks for the ClassLoader.
>>
>> If there are anonymous classes (invokedynamic classes) attributed to the ClassLoader, the following additional information is listed:
>> * The number of anonymous classes loaded by the ClassLoader.
>> * The total size of all allocated metaspace chunks for anonymous classes in the ClassLoader.
>> * The total size of all allocated metaspace blocks for anonymous classes in the ClassLoader.
>>
>> The information is gathered during a safe point to guarantee that the data structures are consistent.
>>
>> I have added a small test and have run this through jprt. A CCC request has been filed.
>>
>> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
>>
>> Example output:
>>
>> ClassLoader Parent CLData* Classes ChunkSz BlockSz Type
>
> We usually say ClassLoaderData or CLD in the code, but never CLData. Could this be changed to CLD* or CLD? I guess ClassLoaderData would be too long. Erik also had a suggestion on a more user-friendly name, I'm fine with that as well.
Changed it to CLD*.
>
>> 0x00000007c002d908 0x0000000000000000 0x0000000000000000 0 0 0 sun.misc.Launcher$ExtClassLoader
>> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761 4694016 4241312 <boot classloader>
>> 37 75776 50928 + invokedynamic classes
>> 0x00000007c0061028 0x00000007c0036878 0x00007fb239c2de60 1 6144 1976 ClassLoaderStatsTest$DummyClassLoader
>> 1 2048 1288 + invokedynamic classes
>> 0x00000007c0036878 0x00000007c002d908 0x00007fb239e10fc0 8 88064 31544 sun.misc.Launcher$AppClassLoader
>> Total = 4 808 4866048 4327048
>> ChunkSz: Total size of all allocated metaspace chunks
>> BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)
>
> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.hpp.html
>
> Is there a reason why these are intx instead of uintx?
>
> 113 intx _total_loaders;
> 114 intx _total_classes;
Changed to uintx.
>
>
> Would you mind changing the name of _classloader to _class_loader?
>
> 69 class ClassLoaderStats : public ResourceObj {
> 70 public:
> 71 ClassLoaderData* _cld;
> 72 Klass* _classloader;
Fixed.
>
>
>
> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.cpp.html
>
> There's a couple of usages of SSIZE_FORMAT_W where I think you should be using SIZE_FORMAT_W
Fixed.
>
>
> At some point it would be nice to have an option to be able to list the usages of all individual anonymous class loaders.
>
>
> http://cr.openjdk.java.net/~sla/8044107/webrev.02/test/serviceability/dcmd/ClassLoaderStatsTest.java.html
>
> I don't know if this is a common style in our testing, but I often read test code without the aid of an IDE so import statements with *s make it harder for me to understand where imported classes come from:
>
> 31 import java.nio.*;
> 32 import java.nio.channels.*;
> 33 import java.io.*;
> 34 import java.util.regex.Matcher;
> 35 import java.util.regex.Pattern;
I agree that this is sloppy. Fixed.
updated webrev is here: http://cr.openjdk.java.net/~sla/8044107/webrev.03/
Thanks,
/Staffan
>
>
> thanks,
> StefanK
>
>>
>>
>> Thanks,
>> /Staffan
From daniel.daugherty at oracle.com Tue Jun 3 13:15:37 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 03 Jun 2014 07:15:37 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <538DC709.5030907@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<538CD7AD.6080900@oracle.com> <538DC709.5030907@oracle.com>
Message-ID: <538DCA79.4010800@oracle.com>
Thanks!
Dan
On 6/3/14 7:00 AM, Zhengyu Gu wrote:
> Look good.
>
> -Zhengyu
>
> On 6/2/2014 3:59 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Need a sanity check review for the JDK8u-hs backport of this fix:
>>
>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8036823-webrev/0-jdk8u-hs
>>
>> The fix backported cleanly; JPRT is running the test right now;
>> Aurora Adhoc testing run will be started when JPRT is done...
>>
>> Dan
>>
>>
>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>> One more round of review after refactoring the test based on comments
>>> from David H and Serguei.
>>>
>>> Here's the webrev for this round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>
>>> Had to change the default sample size from 30 -> 15 in order to
>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>
>>>> Here's the webrev URL for the next round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>
>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>> The new test has been run with the fix via JPRT and passes on all
>>>> JPRT platforms. The new test has also been run without the fix and
>>>> fails on most platforms. Since the default sample size is just 30,
>>>> it is possible to get 30 runs in a row without failing.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>> This is a simple fix for incorrect lock state.
>>>>>
>>>>> The timing on setting thread's pending monitor can result stack
>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>> check the monitor's owner, if the owner is other than the current
>>>>> thread, then the monitor, is or is in process of being, set the
>>>>> pending monitor of current thread.
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
From lev.priima at oracle.com Tue Jun 3 14:25:01 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 03 Jun 2014 18:25:01 +0400
Subject: [9] RFR (XS) 8044339: wrong comment for FilterSpuriousWakeups
option
In-Reply-To: <538D7FA8.6020401@oracle.com>
References: <53877D90.7090105@oracle.com>
<53881F1B.4090805@oracle.com> <5388AA5C.2060207@oracle.com>
<538BF2C8.3010102@oracle.com> <538C4257.2030609@oracle.com>
<538D323D.4010206@oracle.com> <538D7FA8.6020401@oracle.com>
Message-ID: <538DDABD.20208@oracle.com>
Thanks David and Igor!
Anyway, I think it's easier to find a second reviewer, if he does not
have to be a sponsor. Maybe someone will review this update:
http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.03/
Lev
On 06/03/2014 11:56 AM, Igor Ignatyev wrote:
> Lev,
>
> 1. You have a typo in 'src/os/linux/vm/os_linux.cpp':
>> 5541 // We We ignore spurious OS wakeups unless
>> FilterSpuriousWakeups is false.
> ^
> 2. According to the process[1], you need to write a regression test or
> add a 'noreg-*' label to the bug. I think adding 'noreg-doc' is a good
> choice.
>
> Otherwise, your changes look good to me. I'm not a Reviewer, but I
> doubt that such changes require review from two Reviewers, so if
> there's no objections, I'll sponsor your changes.
>
> [1] http://openjdk.java.net/guide/changePlanning.html
>
> Thanks
> Igor
>
> On 06/03/2014 06:26 AM, David Holmes wrote:
>> Looks good to me!
>>
>> You'll need a second reviewer and a sponsor.
>>
>> Thanks,
>> David
>>
>> On 2/06/2014 7:22 PM, Lev Priima wrote:
>>> Thanks, please review update:
>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.02/
>>>
>>> Lev
>>>
>>> On 06/02/2014 07:43 AM, David Holmes wrote:
>>>> Hi Lev,
>>>>
>>>> On 31/05/2014 1:57 AM, Lev Priima wrote:
>>>>> Thanks for comments, please look at update:
>>>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.01/
>>>>
>>>> Please generalize the CR summary and description if you are going to
>>>> pursue all these changes. But include additional information to
>>>> clarify why you made the changes in the os_XXX.cpp files please. On
>>>> that note can you please change:
>>>>
>>>> ! // We must filter out spurious wakeups.
>>>>
>>>> to
>>>>
>>>> ! // We ignore spurious OS wakeups unless FilterSpuriousWakeups is
>>>> false
>>>>
>>>> In globals.hpp: Note that CompilerThreadHintNoPreempt and
>>>> VMThreadHintNoPreempt are actually only meaningful on Solaris. They
>>>> guard the call to os::hint_no_preempt which is a no-op except on
>>>> Solaris. So those changes should be reverted.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>>> On 05/30/2014 10:03 AM, David Holmes wrote:
>>>>>> Hi Lev,
>>>>>>
>>>>>> On 30/05/2014 4:33 AM, Lev Priima wrote:
>>>>>>> Please review and help me with integration:
>>>>>>>
>>>>>>> diff -r 102506d9d873 src/share/vm/runtime/globals.hpp
>>>>>>> --- a/src/share/vm/runtime/globals.hpp Wed May 28 14:42:00 2014
>>>>>>> +0400
>>>>>>> +++ b/src/share/vm/runtime/globals.hpp Thu May 29 22:29:37 2014
>>>>>>> +0400
>>>>>>> @@ -1144,7 +1144,7 @@
>>>>>>> \
>>>>>>> product(bool, FilterSpuriousWakeups,
>>>>>>> true, \
>>>>>>> "Prevent spurious or premature wakeups from object.wait
>>>>>>> " \
>>>>>>> - "(Solaris
>>>>>>> only)") \
>>>>>>> + "(Ignored for
>>>>>>> Windows)") \
>>>>>>> \
>>>>>>
>>>>>> Sorry to make life complicated but as I put in the bug report:
>>>>>>
>>>>>> The "Solaris" part dates from the days when Solaris meant "not
>>>>>> Windows". :)
>>>>>>
>>>>>> A bigger problem here is that the main part of the description:
>>>>>>
>>>>>> "Prevent spurious or premature wakeups from object.wait "
>>>>>>
>>>>>> may not match what people expect - it depends on whether "filter"
>>>>>> means to remove the item being filtered, or to keep only the item
>>>>>> being filtered. It would clearer if it read "When true prevents ..."
>>>>>> but even then it is not accurate as this only excludes spurious
>>>>>> wakeups from the OS pthread_cond[timed]wait implementation - the JVM
>>>>>> can still induce its own "spurious wakeups". So the better
>>>>>> description
>>>>>> would be:
>>>>>>
>>>>>> "When true prevents OS-level spurious, or premature, wakeups from
>>>>>> Object.wait"
>>>>>>
>>>>>> But it should also be noted that where this flag is checked there is
>>>>>> an even more inaccurate comment:
>>>>>>
>>>>>> // The underlying Solaris implementation, cond_timedwait, admits
>>>>>> // spurious/premature wakeups, but the JLS/JVM spec prevents the
>>>>>> // JVM from making those visible to Java code.
>>>>>>
>>>>>> Ironically this comment appears in the linux and bsd versions but
>>>>>> not
>>>>>> the Solaris one! Further it is incorrect - the JLS/JVMS does not
>>>>>> prevent spurious wakeups from being made visible to Java code. That
>>>>>> has always been the intent but it took until Java 5 before we got
>>>>>> the
>>>>>> specification for Object.wait updated to make it clear.
>>>>>>
>>>>>> So really this is all legacy crud that should be removed along with
>>>>>> the other planned cleanups (ie removing the safe_cond_* functions
>>>>>> and
>>>>>> WorkAroundNPTLTimedWaitHang) and the os_posix refactoring.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Sorry to mess up your "starter" bug.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> product(intx, NativeMonitorTimeout, -1,
>>>>>>> "(Unstable)") \
>>>>>>> \
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044339
>>>>>>>
>>>>>
>>>
From vladimir.kozlov at oracle.com Tue Jun 3 17:36:09 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 03 Jun 2014 10:36:09 -0700
Subject: [9] RFR (XS) 8044339: wrong comment for FilterSpuriousWakeups
option
In-Reply-To: <538DDABD.20208@oracle.com>
References: <53877D90.7090105@oracle.com> <53881F1B.4090805@oracle.com> <5388AA5C.2060207@oracle.com> <538BF2C8.3010102@oracle.com> <538C4257.2030609@oracle.com> <538D323D.4010206@oracle.com>
<538D7FA8.6020401@oracle.com> <538DDABD.20208@oracle.com>
Message-ID: <538E0789.3020304@oracle.com>
Looks good.
Vladimir
On 6/3/14 7:25 AM, Lev Priima wrote:
> Thanks David and Igor!
> Anyway, I think it's easier to find a second reviewer, if he does not have to be a sponsor. Maybe someone will review
> this update:
>
> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.03/
>
> Lev
>
> On 06/03/2014 11:56 AM, Igor Ignatyev wrote:
>> Lev,
>>
>> 1. You have a typo in 'src/os/linux/vm/os_linux.cpp':
>>> 5541 // We We ignore spurious OS wakeups unless FilterSpuriousWakeups is false.
>> ^
>> 2. According to the process[1], you need to write a regression test or add a 'noreg-*' label to the bug. I think
>> adding 'noreg-doc' is a good choice.
>>
>> Otherwise, your changes look good to me. I'm not a Reviewer, but I doubt that such changes require review from two
>> Reviewers, so if there's no objections, I'll sponsor your changes.
>>
>> [1] http://openjdk.java.net/guide/changePlanning.html
>>
>> Thanks
>> Igor
>>
>> On 06/03/2014 06:26 AM, David Holmes wrote:
>>> Looks good to me!
>>>
>>> You'll need a second reviewer and a sponsor.
>>>
>>> Thanks,
>>> David
>>>
>>> On 2/06/2014 7:22 PM, Lev Priima wrote:
>>>> Thanks, please review update:
>>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.02/
>>>>
>>>> Lev
>>>>
>>>> On 06/02/2014 07:43 AM, David Holmes wrote:
>>>>> Hi Lev,
>>>>>
>>>>> On 31/05/2014 1:57 AM, Lev Priima wrote:
>>>>>> Thanks for comments, please look at update:
>>>>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.01/
>>>>>
>>>>> Please generalize the CR summary and description if you are going to
>>>>> pursue all these changes. But include additional information to
>>>>> clarify why you made the changes in the os_XXX.cpp files please. On
>>>>> that note can you please change:
>>>>>
>>>>> ! // We must filter out spurious wakeups.
>>>>>
>>>>> to
>>>>>
>>>>> ! // We ignore spurious OS wakeups unless FilterSpuriousWakeups is
>>>>> false
>>>>>
>>>>> In globals.hpp: Note that CompilerThreadHintNoPreempt and
>>>>> VMThreadHintNoPreempt are actually only meaningful on Solaris. They
>>>>> guard the call to os::hint_no_preempt which is a no-op except on
>>>>> Solaris. So those changes should be reverted.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 05/30/2014 10:03 AM, David Holmes wrote:
>>>>>>> Hi Lev,
>>>>>>>
>>>>>>> On 30/05/2014 4:33 AM, Lev Priima wrote:
>>>>>>>> Please review and help me with integration:
>>>>>>>>
>>>>>>>> diff -r 102506d9d873 src/share/vm/runtime/globals.hpp
>>>>>>>> --- a/src/share/vm/runtime/globals.hpp Wed May 28 14:42:00 2014
>>>>>>>> +0400
>>>>>>>> +++ b/src/share/vm/runtime/globals.hpp Thu May 29 22:29:37 2014
>>>>>>>> +0400
>>>>>>>> @@ -1144,7 +1144,7 @@
>>>>>>>> \
>>>>>>>> product(bool, FilterSpuriousWakeups,
>>>>>>>> true, \
>>>>>>>> "Prevent spurious or premature wakeups from object.wait
>>>>>>>> " \
>>>>>>>> - "(Solaris
>>>>>>>> only)") \
>>>>>>>> + "(Ignored for
>>>>>>>> Windows)") \
>>>>>>>> \
>>>>>>>
>>>>>>> Sorry to make life complicated but as I put in the bug report:
>>>>>>>
>>>>>>> The "Solaris" part dates from the days when Solaris meant "not
>>>>>>> Windows". :)
>>>>>>>
>>>>>>> A bigger problem here is that the main part of the description:
>>>>>>>
>>>>>>> "Prevent spurious or premature wakeups from object.wait "
>>>>>>>
>>>>>>> may not match what people expect - it depends on whether "filter"
>>>>>>> means to remove the item being filtered, or to keep only the item
>>>>>>> being filtered. It would clearer if it read "When true prevents ..."
>>>>>>> but even then it is not accurate as this only excludes spurious
>>>>>>> wakeups from the OS pthread_cond[timed]wait implementation - the JVM
>>>>>>> can still induce its own "spurious wakeups". So the better description
>>>>>>> would be:
>>>>>>>
>>>>>>> "When true prevents OS-level spurious, or premature, wakeups from
>>>>>>> Object.wait"
>>>>>>>
>>>>>>> But it should also be noted that where this flag is checked there is
>>>>>>> an even more inaccurate comment:
>>>>>>>
>>>>>>> // The underlying Solaris implementation, cond_timedwait, admits
>>>>>>> // spurious/premature wakeups, but the JLS/JVM spec prevents the
>>>>>>> // JVM from making those visible to Java code.
>>>>>>>
>>>>>>> Ironically this comment appears in the linux and bsd versions but not
>>>>>>> the Solaris one! Further it is incorrect - the JLS/JVMS does not
>>>>>>> prevent spurious wakeups from being made visible to Java code. That
>>>>>>> has always been the intent but it took until Java 5 before we got the
>>>>>>> specification for Object.wait updated to make it clear.
>>>>>>>
>>>>>>> So really this is all legacy crud that should be removed along with
>>>>>>> the other planned cleanups (ie removing the safe_cond_* functions and
>>>>>>> WorkAroundNPTLTimedWaitHang) and the os_posix refactoring.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> Sorry to mess up your "starter" bug.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> product(intx, NativeMonitorTimeout, -1,
>>>>>>>> "(Unstable)") \
>>>>>>>> \
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044339
>>>>>>>>
>>>>>>
>>>>
>
From lev.priima at oracle.com Tue Jun 3 17:44:32 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 03 Jun 2014 21:44:32 +0400
Subject: [9] RFR (XS) 8044339: wrong comment for FilterSpuriousWakeups
option
In-Reply-To: <538E0789.3020304@oracle.com>
References: <53877D90.7090105@oracle.com> <53881F1B.4090805@oracle.com> <5388AA5C.2060207@oracle.com> <538BF2C8.3010102@oracle.com> <538C4257.2030609@oracle.com> <538D323D.4010206@oracle.com>
<538D7FA8.6020401@oracle.com> <538DDABD.20208@oracle.com>
<538E0789.3020304@oracle.com>
Message-ID: <538E0980.4090704@oracle.com>
Thanks Vladimir,
Lev
On 06/03/2014 09:36 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Vladimir
>
> On 6/3/14 7:25 AM, Lev Priima wrote:
>> Thanks David and Igor!
>> Anyway, I think it's easier to find a second reviewer, if he does not
>> have to be a sponsor. Maybe someone will review
>> this update:
>>
>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.03/
>>
>> Lev
>>
>> On 06/03/2014 11:56 AM, Igor Ignatyev wrote:
>>> Lev,
>>>
>>> 1. You have a typo in 'src/os/linux/vm/os_linux.cpp':
>>>> 5541 // We We ignore spurious OS wakeups unless
>>>> FilterSpuriousWakeups is false.
>>> ^
>>> 2. According to the process[1], you need to write a regression test
>>> or add a 'noreg-*' label to the bug. I think
>>> adding 'noreg-doc' is a good choice.
>>>
>>> Otherwise, your changes look good to me. I'm not a Reviewer, but I
>>> doubt that such changes require review from two
>>> Reviewers, so if there's no objections, I'll sponsor your changes.
>>>
>>> [1] http://openjdk.java.net/guide/changePlanning.html
>>>
>>> Thanks
>>> Igor
>>>
>>> On 06/03/2014 06:26 AM, David Holmes wrote:
>>>> Looks good to me!
>>>>
>>>> You'll need a second reviewer and a sponsor.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 2/06/2014 7:22 PM, Lev Priima wrote:
>>>>> Thanks, please review update:
>>>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.02/
>>>>>
>>>>> Lev
>>>>>
>>>>> On 06/02/2014 07:43 AM, David Holmes wrote:
>>>>>> Hi Lev,
>>>>>>
>>>>>> On 31/05/2014 1:57 AM, Lev Priima wrote:
>>>>>>> Thanks for comments, please look at update:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/lpriima/8044339/webrev.01/
>>>>>>
>>>>>> Please generalize the CR summary and description if you are going to
>>>>>> pursue all these changes. But include additional information to
>>>>>> clarify why you made the changes in the os_XXX.cpp files please. On
>>>>>> that note can you please change:
>>>>>>
>>>>>> ! // We must filter out spurious wakeups.
>>>>>>
>>>>>> to
>>>>>>
>>>>>> ! // We ignore spurious OS wakeups unless FilterSpuriousWakeups is
>>>>>> false
>>>>>>
>>>>>> In globals.hpp: Note that CompilerThreadHintNoPreempt and
>>>>>> VMThreadHintNoPreempt are actually only meaningful on Solaris. They
>>>>>> guard the call to os::hint_no_preempt which is a no-op except on
>>>>>> Solaris. So those changes should be reverted.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 05/30/2014 10:03 AM, David Holmes wrote:
>>>>>>>> Hi Lev,
>>>>>>>>
>>>>>>>> On 30/05/2014 4:33 AM, Lev Priima wrote:
>>>>>>>>> Please review and help me with integration:
>>>>>>>>>
>>>>>>>>> diff -r 102506d9d873 src/share/vm/runtime/globals.hpp
>>>>>>>>> --- a/src/share/vm/runtime/globals.hpp Wed May 28 14:42:00
>>>>>>>>> 2014
>>>>>>>>> +0400
>>>>>>>>> +++ b/src/share/vm/runtime/globals.hpp Thu May 29 22:29:37
>>>>>>>>> 2014
>>>>>>>>> +0400
>>>>>>>>> @@ -1144,7 +1144,7 @@
>>>>>>>>> \
>>>>>>>>> product(bool, FilterSpuriousWakeups,
>>>>>>>>> true, \
>>>>>>>>> "Prevent spurious or premature wakeups from
>>>>>>>>> object.wait
>>>>>>>>> " \
>>>>>>>>> - "(Solaris
>>>>>>>>> only)") \
>>>>>>>>> + "(Ignored for
>>>>>>>>> Windows)") \
>>>>>>>>> \
>>>>>>>>
>>>>>>>> Sorry to make life complicated but as I put in the bug report:
>>>>>>>>
>>>>>>>> The "Solaris" part dates from the days when Solaris meant "not
>>>>>>>> Windows". :)
>>>>>>>>
>>>>>>>> A bigger problem here is that the main part of the description:
>>>>>>>>
>>>>>>>> "Prevent spurious or premature wakeups from object.wait "
>>>>>>>>
>>>>>>>> may not match what people expect - it depends on whether "filter"
>>>>>>>> means to remove the item being filtered, or to keep only the item
>>>>>>>> being filtered. It would clearer if it read "When true prevents
>>>>>>>> ..."
>>>>>>>> but even then it is not accurate as this only excludes spurious
>>>>>>>> wakeups from the OS pthread_cond[timed]wait implementation -
>>>>>>>> the JVM
>>>>>>>> can still induce its own "spurious wakeups". So the better
>>>>>>>> description
>>>>>>>> would be:
>>>>>>>>
>>>>>>>> "When true prevents OS-level spurious, or premature, wakeups from
>>>>>>>> Object.wait"
>>>>>>>>
>>>>>>>> But it should also be noted that where this flag is checked
>>>>>>>> there is
>>>>>>>> an even more inaccurate comment:
>>>>>>>>
>>>>>>>> // The underlying Solaris implementation, cond_timedwait, admits
>>>>>>>> // spurious/premature wakeups, but the JLS/JVM spec prevents the
>>>>>>>> // JVM from making those visible to Java code.
>>>>>>>>
>>>>>>>> Ironically this comment appears in the linux and bsd versions
>>>>>>>> but not
>>>>>>>> the Solaris one! Further it is incorrect - the JLS/JVMS does not
>>>>>>>> prevent spurious wakeups from being made visible to Java code.
>>>>>>>> That
>>>>>>>> has always been the intent but it took until Java 5 before we
>>>>>>>> got the
>>>>>>>> specification for Object.wait updated to make it clear.
>>>>>>>>
>>>>>>>> So really this is all legacy crud that should be removed along
>>>>>>>> with
>>>>>>>> the other planned cleanups (ie removing the safe_cond_*
>>>>>>>> functions and
>>>>>>>> WorkAroundNPTLTimedWaitHang) and the os_posix refactoring.
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Sorry to mess up your "starter" bug.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>>> product(intx, NativeMonitorTimeout, -1,
>>>>>>>>> "(Unstable)") \
>>>>>>>>> \
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044339
>>>>>>>>>
>>>>>>>
>>>>>
>>
From george.triantafillou at oracle.com Tue Jun 3 18:23:09 2014
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Tue, 03 Jun 2014 14:23:09 -0400
Subject: RFR (L) 8044140: [TESTBUG] Create NMT (Native Memory Tracking)
tests for NMT2
In-Reply-To: <003501cf7e75$d7b99190$872cb4b0$@oracle.com>
References: <53861884.1050407@oracle.com> <53861C20.60303@oracle.com>
<53876C27.1070301@oracle.com>
<003501cf7e75$d7b99190$872cb4b0$@oracle.com>
Message-ID: <538E128D.3020500@oracle.com>
Thanks Christian and Zhengyu for the review. Updated webrev:
http://cr.openjdk.java.net/~gtriantafill/bug_8044140/webrev.01/
<http://cr.openjdk.java.net/%7Egtriantafill/bug_8044140/webrev.01/>
-George
On 6/2/2014 11:18 AM, Christian Tornqvist wrote:
> Hi George,
>
> Except for the things Zhengyu mentioned, the only thing I have is if TEST.groups should have 2014 as copyright year as well? Otherwise it looks good, thanks for doing this :)
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of George Triantafillou
> Sent: Thursday, May 29, 2014 1:20 PM
> To: hotspot-dev at openjdk.java.net
> Subject: Re: RFR (L) 8044140: [TESTBUG] Create NMT (Native Memory Tracking) tests for NMT2
>
> Hi Zhengyu,
>
> Thanks for your comments.
>
> On 5/28/2014 1:25 PM, Zhengyu Gu wrote:
>> Hi,
>>
>> JcmdScale.java:
>> There is no change, should not update copyright ...
> Fixed.
>
>> AutoshutdownNMT.java line #42
>>
>> 42 output.shouldContain("Unrecognized VM option
>> 'AutoshutdownNMT'");
>>
>> Should be
>>
>> 42 output.shouldContain("Unrecognized VM option
>> 'AutoShutdownNMT'");
>>
>>
>> Also -XX:-AutoshutdownNMT => -XX:-AutoShutdownNMT
>>
> Fixed.
>
> -George
>> -Zhengyu
>>
>>
>> On 5/28/2014 1:10 PM, George Triantafillou wrote:
>>> Please review these new and modified tests for the redesigned Native
>>> Memory Tracking (NMT) functionality (8028541: Native Memory Tracking
>>> enhancement <https://bugs.openjdk.java.net/browse/JDK-8028541>). NMT
>>> was redesigned internally to address scalability issues in the first
>>> implementation. Existing functionality has not changed, with the
>>> exception of the removal of the "-AutoshutdownNMT" flag.
>>>
>>> Please note that the following new stress tests are excluded with the
>>> JTREG @ignore tag:
>>>
>>> test/runtime/NMT/MallocSiteHashOverflow.java
>>> test/runtime/NMT/MallocStressTest.java
>>>
>>> These tests can be run by using the jtreg override option
>>> "-ignore:run". The new key "@key stress" was also added to these tests.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8044140
>>> Webrev:
>>> http://cr.openjdk.java.net/~gtriantafill/bug_8044140/webrev.00/
>>> <http://cr.openjdk.java.net/%7Egtriantafill/bug_8044140/webrev.00/>
>>> Testing: JTREG to exercise the added tests
>>>
>>> Thank you,
>>>
>>> George
>
From staffan.larsen at oracle.com Tue Jun 3 18:31:26 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 3 Jun 2014 20:31:26 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <4DA91FF1-334E-4613-BCB4-837BD8A36683@oracle.com>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
<538D93C0.2080103@oracle.com>
<4DA91FF1-334E-4613-BCB4-837BD8A36683@oracle.com>
Message-ID: <EECBB520-F0B0-45EC-B6CB-388EA46FA859@oracle.com>
On 3 jun 2014, at 15:11, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> Stefan, thanks for the comments. See below.
>
> On 3 jun 2014, at 11:22, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>
>> Hi Staffan,
>>
>> Thanks for implementing this feature!
>>
>> On 2014-05-28 16:50, Staffan Larsen wrote:
>>> This change adds a new Diagnostic Command to list all ClassLoaders and some statistics for each classloader. The command is called ?GC.classloader_stats? and the information listed is:
>>>
>>> * An id for the ClassLoader. This is the pointer to the Klass of the ClassLoader. The reason for using the Klass* (instead of the oop) is that it is stable across invocations.
>>
>> I agree that it's good to get a stable value, but IMHO the code would be easier if you just stored the oops for _classloader and _parent instead of the Klass*.
>>
>> 71 ClassLoaderData* _cld;
>> 72 Klass* _classloader;
>> 73 Klass* _parent;
>>
>>
>> This will work since all this is done during a safe point.
>
> The reason I choose Klass* was that I wanted something that was stable /across/ invocations, not just during one invocation of the Diagnostic Command. That way you can compare the output over time.
I spoke to Stefan offline and understood that he was ok with printing out the Klass*, but did not like to have them stored in the ClassLoaderStats fields. I misunderstood that.
So here is an updated version that stores class loader and parent as oops, but prints them as Klass*.
http://cr.openjdk.java.net/~sla/8044107/webrev.04/
Thanks,
/Staffan
>
>> As the code is written right now, it's awkward that we put Klass*s in fields named _parent and _classloader. We usually put oops and CLD*s in fields that are named that way.
>
> I can change the names of the fields. Suggestions?
>
>>
>> The following code:
>>
>> 144 // It does not exist in our table - add it
>> 145 ClassLoaderStats* cls = new ClassLoaderStats();
>> 146 cls->_classloader = cl->klass();
>> 147 oop parent = java_lang_ClassLoader::parent(cl);
>> 148 if (parent != NULL) {
>> 149 cls->_parent = parent->klass();
>> 150 }
>>
>> could be condensed down to:
>>
>> 144 // It does not exist in our table - add it
>> 145 ClassLoaderStats* cls = new ClassLoaderStats();
>> 146 cls->_classloader = cl
>> 147 cls->_parent = java_lang_ClassLoader::parent(cl);
>>
>> or even:
>>
>> 144 // It does not exist in our table - add it
>> 145 ClassLoaderStats* cls = new ClassLoaderStats(cl, java_lang_ClassLoader::parent(cl));
>>
>>
>> and
>>
>> 63 cls->_classloader = (cl == NULL ? NULL : cl->klass());
>> 64 if (cl != NULL) {
>> 65 oop parent = java_lang_ClassLoader::parent(cl);
>> 66 if (parent != NULL) {
>> 67 cls->_parent = parent->klass();
>> 68 addEmptyParents(parent);
>> 69 }
>> 70 }
>>
>> would be come:
>>
>> 63 cls->_classloader = cl;
>> 64 if (cl != NULL) {
>> 65 cls->_parent = java_lang_ClassLoader::parent(cl);
>> 68 addEmptyParents(cls->_parent);
>> 70 }
>>
>>
>>> * The id of the ClassLoader?s parent ClassLoader.
>>> * The pointer to the ClassLoaderData structure in the VM. This can be useful for debugging.
>>> * The number of classes loaded by the ClassLoader.
>>> * The total size of all allocated metaspace chunks for the ClassLoader.
>>> * The total size of all allocated metaspace blocks for the ClassLoader.
>>>
>>> If there are anonymous classes (invokedynamic classes) attributed to the ClassLoader, the following additional information is listed:
>>> * The number of anonymous classes loaded by the ClassLoader.
>>> * The total size of all allocated metaspace chunks for anonymous classes in the ClassLoader.
>>> * The total size of all allocated metaspace blocks for anonymous classes in the ClassLoader.
>>>
>>> The information is gathered during a safe point to guarantee that the data structures are consistent.
>>>
>>> I have added a small test and have run this through jprt. A CCC request has been filed.
>>>
>>> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
>>>
>>> Example output:
>>>
>>> ClassLoader Parent CLData* Classes ChunkSz BlockSz Type
>>
>> We usually say ClassLoaderData or CLD in the code, but never CLData. Could this be changed to CLD* or CLD? I guess ClassLoaderData would be too long. Erik also had a suggestion on a more user-friendly name, I'm fine with that as well.
>
> Changed it to CLD*.
>
>>
>>> 0x00000007c002d908 0x0000000000000000 0x0000000000000000 0 0 0 sun.misc.Launcher$ExtClassLoader
>>> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761 4694016 4241312 <boot classloader>
>>> 37 75776 50928 + invokedynamic classes
>>> 0x00000007c0061028 0x00000007c0036878 0x00007fb239c2de60 1 6144 1976 ClassLoaderStatsTest$DummyClassLoader
>>> 1 2048 1288 + invokedynamic classes
>>> 0x00000007c0036878 0x00000007c002d908 0x00007fb239e10fc0 8 88064 31544 sun.misc.Launcher$AppClassLoader
>>> Total = 4 808 4866048 4327048
>>> ChunkSz: Total size of all allocated metaspace chunks
>>> BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)
>>
>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.hpp.html
>>
>> Is there a reason why these are intx instead of uintx?
>>
>> 113 intx _total_loaders;
>> 114 intx _total_classes;
>
> Changed to uintx.
>
>>
>>
>> Would you mind changing the name of _classloader to _class_loader?
>>
>> 69 class ClassLoaderStats : public ResourceObj {
>> 70 public:
>> 71 ClassLoaderData* _cld;
>> 72 Klass* _classloader;
>
> Fixed.
>
>>
>>
>>
>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.cpp.html
>>
>> There's a couple of usages of SSIZE_FORMAT_W where I think you should be using SIZE_FORMAT_W
>
> Fixed.
>
>>
>>
>> At some point it would be nice to have an option to be able to list the usages of all individual anonymous class loaders.
>>
>>
>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/test/serviceability/dcmd/ClassLoaderStatsTest.java.html
>>
>> I don't know if this is a common style in our testing, but I often read test code without the aid of an IDE so import statements with *s make it harder for me to understand where imported classes come from:
>>
>> 31 import java.nio.*;
>> 32 import java.nio.channels.*;
>> 33 import java.io.*;
>> 34 import java.util.regex.Matcher;
>> 35 import java.util.regex.Pattern;
>
> I agree that this is sloppy. Fixed.
>
> updated webrev is here: http://cr.openjdk.java.net/~sla/8044107/webrev.03/
>
> Thanks,
> /Staffan
>
>>
>>
>> thanks,
>> StefanK
>>
>>>
>>>
>>> Thanks,
>>> /Staffan
From stefan.karlsson at oracle.com Tue Jun 3 19:00:11 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 03 Jun 2014 21:00:11 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <EECBB520-F0B0-45EC-B6CB-388EA46FA859@oracle.com>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
<538D93C0.2080103@oracle.com>
<4DA91FF1-334E-4613-BCB4-837BD8A36683@oracle.com>
<EECBB520-F0B0-45EC-B6CB-388EA46FA859@oracle.com>
Message-ID: <538E1B3B.2030608@oracle.com>
On 2014-06-03 20:31, Staffan Larsen wrote:
>
> On 3 jun 2014, at 15:11, Staffan Larsen <staffan.larsen at oracle.com
> <mailto:staffan.larsen at oracle.com>> wrote:
>
>> Stefan, thanks for the comments. See below.
>>
>> On 3 jun 2014, at 11:22, Stefan Karlsson <stefan.karlsson at oracle.com
>> <mailto:stefan.karlsson at oracle.com>> wrote:
>>
>>> Hi Staffan,
>>>
>>> Thanks for implementing this feature!
>>>
>>> On 2014-05-28 16:50, Staffan Larsen wrote:
>>>> This change adds a new Diagnostic Command to list all ClassLoaders
>>>> and some statistics for each classloader. The command is called
>>>> ?GC.classloader_stats? and the information listed is:
>>>>
>>>> * An id for the ClassLoader. This is the pointer to the Klass of
>>>> the ClassLoader. The reason for using the Klass* (instead of the
>>>> oop) is that it is stable across invocations.
>>>
>>> I agree that it's good to get a stable value, but IMHO the code
>>> would be easier if you just stored the oops for _classloader and
>>> _parent instead of the Klass*.
>>>
>>> 71 ClassLoaderData* _cld;
>>> 72 Klass* _classloader;
>>> 73 Klass* _parent;
>>>
>>>
>>> This will work since all this is done during a safe point.
>>
>> The reason I choose Klass* was that I wanted something that was
>> stable /across/ invocations, not just during one invocation of the
>> Diagnostic Command. That way you can compare the output over time.
>
> I spoke to Stefan offline and understood that he was ok with printing
> out the Klass*, but did not like to have them stored in
> the ClassLoaderStats fields. I misunderstood that.
>
> So here is an updated version that stores class loader and parent as
> oops, but prints them as Klass*.
>
> http://cr.openjdk.java.net/~sla/8044107/webrev.04/
> <http://cr.openjdk.java.net/%7Esla/8044107/webrev.04/>
Thanks for doing these changes.
I think I found a bug in the test:
86 Matcher m1 = anonLine.matcher(next);
87 m1.matches();
88 if (!m1.group(1).equals("1")) {
89 throw new Exception("Should have loaded 1 anonymous class, but found : " + m1.group(1));
90 }
91 checkPositiveInt(m.group(2));
92 checkPositiveInt(m.group(3));
Shouldn't line 91 and 92 be looking at m1?
Other than that, this looks good.
thanks,
StefanK
>
> Thanks,
> /Staffan
>
>
>
>>
>>> As the code is written right now, it's awkward that we put Klass*s
>>> in fields named _parent and _classloader. We usually put oops and
>>> CLD*s in fields that are named that way.
>>
>> I can change the names of the fields. Suggestions?
>>
>>>
>>> The following code:
>>>
>>> 144 // It does not exist in our table - add it
>>> 145 ClassLoaderStats* cls = new ClassLoaderStats();
>>> 146 cls->_classloader = cl->klass();
>>> 147 oop parent = java_lang_ClassLoader::parent(cl);
>>> 148 if (parent != NULL) {
>>> 149 cls->_parent = parent->klass();
>>> 150 }
>>>
>>> could be condensed down to:
>>>
>>> 144 // It does not exist in our table - add it
>>> 145 ClassLoaderStats* cls = new ClassLoaderStats();
>>> 146 cls->_classloader = cl
>>> 147 cls->_parent = java_lang_ClassLoader::parent(cl);
>>>
>>> or even:
>>>
>>> 144 // It does not exist in our table - add it
>>> 145 ClassLoaderStats* cls = new ClassLoaderStats(cl,
>>> java_lang_ClassLoader::parent(cl));
>>>
>>>
>>> and
>>>
>>> 63 cls->_classloader = (cl == NULL ? NULL : cl->klass());
>>> 64 if (cl != NULL) {
>>> 65 oop parent = java_lang_ClassLoader::parent(cl);
>>> 66 if (parent != NULL) {
>>> 67 cls->_parent = parent->klass();
>>> 68 addEmptyParents(parent);
>>> 69 }
>>> 70 }
>>>
>>> would be come:
>>>
>>> 63 cls->_classloader = cl;
>>> 64 if (cl != NULL) {
>>> 65 cls->_parent = java_lang_ClassLoader::parent(cl);
>>> 68 addEmptyParents(cls->_parent);
>>> 70 }
>>>
>>>
>>>> * The id of the ClassLoader?s parent ClassLoader.
>>>> * The pointer to the ClassLoaderData structure in the VM. This can
>>>> be useful for debugging.
>>>> * The number of classes loaded by the ClassLoader.
>>>> * The total size of all allocated metaspace chunks for the ClassLoader.
>>>> * The total size of all allocated metaspace blocks for the ClassLoader.
>>>>
>>>> If there are anonymous classes (invokedynamic classes) attributed
>>>> to the ClassLoader, the following additional information is listed:
>>>> * The number of anonymous classes loaded by the ClassLoader.
>>>> * The total size of all allocated metaspace chunks for anonymous
>>>> classes in the ClassLoader.
>>>> * The total size of all allocated metaspace blocks for anonymous
>>>> classes in the ClassLoader.
>>>>
>>>> The information is gathered during a safe point to guarantee that
>>>> the data structures are consistent.
>>>>
>>>> I have added a small test and have run this through jprt. A CCC
>>>> request has been filed.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Esla/8044107/webrev.00/>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
>>>>
>>>> Example output:
>>>>
>>>> ClassLoader Parent CLData* Classes
>>>> ChunkSz BlockSz Type
>>>
>>> We usually say ClassLoaderData or CLD in the code, but never CLData.
>>> Could this be changed to CLD* or CLD? I guess ClassLoaderData would
>>> be too long. Erik also had a suggestion on a more user-friendly
>>> name, I'm fine with that as well.
>>
>> Changed it to CLD*.
>>
>>>
>>>> 0x00000007c002d908 0x0000000000000000 0x0000000000000000 0
>>>> 0 0 sun.misc.Launcher$ExtClassLoader
>>>> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761
>>>> 4694016 4241312 <boot classloader>
>>>> 37
>>>> 75776 50928 + invokedynamic classes
>>>> 0x00000007c0061028 0x00000007c0036878 0x00007fb239c2de60 1
>>>> 6144 1976 ClassLoaderStatsTest$DummyClassLoader
>>>> 1
>>>> 2048 1288 + invokedynamic classes
>>>> 0x00000007c0036878 0x00000007c002d908 0x00007fb239e10fc0 8
>>>> 88064 31544 sun.misc.Launcher$AppClassLoader
>>>> Total = 4 808
>>>> 4866048 4327048
>>>> ChunkSz: Total size of all allocated metaspace chunks
>>>> BlockSz: Total size of all allocated metaspace blocks (each chunk
>>>> has several blocks)
>>>
>>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.hpp.html
>>> <http://cr.openjdk.java.net/%7Esla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.hpp.html>
>>>
>>> Is there a reason why these are intx instead of uintx?
>>>
>>> 113 intx _total_loaders;
>>> 114 intx _total_classes;
>>
>> Changed to uintx.
>>
>>>
>>>
>>> Would you mind changing the name of _classloader to _class_loader?
>>>
>>> 69 class ClassLoaderStats : public ResourceObj {
>>> 70 public:
>>> 71 ClassLoaderData* _cld;
>>> 72 Klass* _classloader;
>>
>> Fixed.
>>
>>>
>>>
>>>
>>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.cpp.html
>>> <http://cr.openjdk.java.net/%7Esla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.cpp.html>
>>>
>>> There's a couple of usages of SSIZE_FORMAT_W where I think you
>>> should be using SIZE_FORMAT_W
>>
>> Fixed.
>>
>>>
>>>
>>> At some point it would be nice to have an option to be able to list
>>> the usages of all individual anonymous class loaders.
>>>
>>>
>>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/test/serviceability/dcmd/ClassLoaderStatsTest.java.html
>>> <http://cr.openjdk.java.net/%7Esla/8044107/webrev.02/test/serviceability/dcmd/ClassLoaderStatsTest.java.html>
>>>
>>> I don't know if this is a common style in our testing, but I often
>>> read test code without the aid of an IDE so import statements with
>>> *s make it harder for me to understand where imported classes come from:
>>>
>>> 31 import java.nio.*;
>>> 32 import java.nio.channels.*;
>>> 33 import java.io.*;
>>> 34 import java.util.regex.Matcher;
>>> 35 import java.util.regex.Pattern;
>>
>> I agree that this is sloppy. Fixed.
>>
>> updated webrev is
>> here:http://cr.openjdk.java.net/~sla/8044107/webrev.03/
>> <http://cr.openjdk.java.net/%7Esla/8044107/webrev.03/>
>>
>> Thanks,
>> /Staffan
>>
>>>
>>>
>>> thanks,
>>> StefanK
>>>
>>>>
>>>>
>>>> Thanks,
>>>> /Staffan
>
From mikael.vidstedt at oracle.com Tue Jun 3 23:52:22 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 03 Jun 2014 16:52:22 -0700
Subject: RFR (S): 8044735: Print format/argument warnings
Message-ID: <538E5FB6.1010909@oracle.com>
Please review this small change which addresses some (additional) printf
format/argument mismatch warnings when compiling sparc files with gcc. A
previous change (JDK-8044071) fixed it for the product version of
Hotspot. This time around it's for warnings when compiling the debug
version(s).
Bug: https://bugs.openjdk.java.net/browse/JDK-8044735
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8044735/webrev.01/webrev/
Cheers,
Mikael
From christian.thalinger at oracle.com Wed Jun 4 00:08:37 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 3 Jun 2014 17:08:37 -0700
Subject: RFR (S): 8044735: Print format/argument warnings
In-Reply-To: <538E5FB6.1010909@oracle.com>
References: <538E5FB6.1010909@oracle.com>
Message-ID: <F08303E3-09A6-4596-BB8E-5F3B920DF28E@oracle.com>
Looks good. The only thing you could change is using print_cr here:
! tty->print("register window backtrace from " INTPTR_FORMAT ":\n", p2i(sp));
On Jun 3, 2014, at 4:52 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>
> Please review this small change which addresses some (additional) printf format/argument mismatch warnings when compiling sparc files with gcc. A previous change (JDK-8044071) fixed it for the product version of Hotspot. This time around it's for warnings when compiling the debug version(s).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044735
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8044735/webrev.01/webrev/
>
> Cheers,
> Mikael
>
From vladimir.kozlov at oracle.com Wed Jun 4 00:09:51 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 03 Jun 2014 17:09:51 -0700
Subject: RFR (S): 8044735: Print format/argument warnings
In-Reply-To: <538E5FB6.1010909@oracle.com>
References: <538E5FB6.1010909@oracle.com>
Message-ID: <538E63CF.8090900@oracle.com>
Looks good.
Vladimir
On 6/3/14 4:52 PM, Mikael Vidstedt wrote:
>
> Please review this small change which addresses some (additional) printf
> format/argument mismatch warnings when compiling sparc files with gcc. A
> previous change (JDK-8044071) fixed it for the product version of
> Hotspot. This time around it's for warnings when compiling the debug
> version(s).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044735
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8044735/webrev.01/webrev/
>
> Cheers,
> Mikael
>
From mikael.vidstedt at oracle.com Wed Jun 4 01:24:06 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 03 Jun 2014 18:24:06 -0700
Subject: RFR (S): 8044735: Print format/argument warnings
In-Reply-To: <F08303E3-09A6-4596-BB8E-5F3B920DF28E@oracle.com>
References: <538E5FB6.1010909@oracle.com>
<F08303E3-09A6-4596-BB8E-5F3B920DF28E@oracle.com>
Message-ID: <538E7536.2040101@oracle.com>
Vladimir/Chris - thanks for the reviews! I'll change to a print_cr (and
remove the \n) before I commit.
Cheers,
Mikael
On 2014-06-03 17:08, Christian Thalinger wrote:
> Looks good. The only thing you could change is using print_cr here:
> *! tty->print("register window backtrace from_" INTPTR_FORMAT ":\n", p2i(sp)_);*
> *
> *
> On Jun 3, 2014, at 4:52 PM, Mikael Vidstedt
> <mikael.vidstedt at oracle.com <mailto:mikael.vidstedt at oracle.com>> wrote:
>
>>
>> Please review this small change which addresses some (additional)
>> printf format/argument mismatch warnings when compiling sparc files
>> with gcc. A previous change (JDK-8044071) fixed it for the product
>> version of Hotspot. This time around it's for warnings when compiling
>> the debug version(s).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044735
>> Webrev:
>> http://cr.openjdk.java.net/~mikael/webrevs/8044735/webrev.01/webrev/
>> <http://cr.openjdk.java.net/%7Emikael/webrevs/8044735/webrev.01/webrev/>
>>
>> Cheers,
>> Mikael
>>
>
From albert.noll at oracle.com Wed Jun 4 04:44:28 2014
From: albert.noll at oracle.com (Albert)
Date: Wed, 04 Jun 2014 06:44:28 +0200
Subject: [8u20] RFR(S): 8011646 : SEGV in compiled code with loop predication
Message-ID: <538EA42C.4000601@oracle.com>
Hi,
I would like to request a 8u20 backport of JDK-8011646.
The changes were pushed to 9 on 2014-05-30. Nightly testing showed no
problems.
The changes applied to 8u20 without conflicts.
Master bug: https://bugs.openjdk.java.net/browse/JDK-8011646
Webrev: http://cr.openjdk.java.net/~anoll/8011646/webrev.00/
Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/774578bd0cb4
Thanks,
Albert
From vladimir.kozlov at oracle.com Wed Jun 4 05:27:38 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 03 Jun 2014 22:27:38 -0700
Subject: [8u20] RFR(S): 8011646 : SEGV in compiled code with loop
predication
In-Reply-To: <538EA42C.4000601@oracle.com>
References: <538EA42C.4000601@oracle.com>
Message-ID: <538EAE4A.2060302@oracle.com>
Looks good.
You are lucky that is was pushed into jdk9 before 8034812 changes :)
Vladimir
On 6/3/14 9:44 PM, Albert wrote:
> Hi,
> I would like to request a 8u20 backport of JDK-8011646.
>
> The changes were pushed to 9 on 2014-05-30. Nightly testing showed no
> problems.
> The changes applied to 8u20 without conflicts.
>
> Master bug: https://bugs.openjdk.java.net/browse/JDK-8011646
> Webrev: http://cr.openjdk.java.net/~anoll/8011646/webrev.00/
> Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/774578bd0cb4
>
> Thanks,
> Albert
>
From staffan.larsen at oracle.com Wed Jun 4 07:50:00 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 4 Jun 2014 09:50:00 +0200
Subject: RFR: 8044107 Add Diagnostic Command to list all ClassLoaders
In-Reply-To: <538E1B3B.2030608@oracle.com>
References: <3921F7BD-DB5B-4610-B126-9CA89D5C381C@oracle.com>
<538D93C0.2080103@oracle.com>
<4DA91FF1-334E-4613-BCB4-837BD8A36683@oracle.com>
<EECBB520-F0B0-45EC-B6CB-388EA46FA859@oracle.com>
<538E1B3B.2030608@oracle.com>
Message-ID: <D8F7C966-B4C3-4EFD-892D-AB33B9ED1057@oracle.com>
On 3 jun 2014, at 21:00, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> On 2014-06-03 20:31, Staffan Larsen wrote:
>>
>> On 3 jun 2014, at 15:11, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>
>>> Stefan, thanks for the comments. See below.
>>>
>>> On 3 jun 2014, at 11:22, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>>
>>>> Hi Staffan,
>>>>
>>>> Thanks for implementing this feature!
>>>>
>>>> On 2014-05-28 16:50, Staffan Larsen wrote:
>>>>> This change adds a new Diagnostic Command to list all ClassLoaders and some statistics for each classloader. The command is called ?GC.classloader_stats? and the information listed is:
>>>>>
>>>>> * An id for the ClassLoader. This is the pointer to the Klass of the ClassLoader. The reason for using the Klass* (instead of the oop) is that it is stable across invocations.
>>>>
>>>> I agree that it's good to get a stable value, but IMHO the code would be easier if you just stored the oops for _classloader and _parent instead of the Klass*.
>>>>
>>>> 71 ClassLoaderData* _cld;
>>>> 72 Klass* _classloader;
>>>> 73 Klass* _parent;
>>>>
>>>>
>>>> This will work since all this is done during a safe point.
>>>
>>> The reason I choose Klass* was that I wanted something that was stable /across/ invocations, not just during one invocation of the Diagnostic Command. That way you can compare the output over time.
>>
>> I spoke to Stefan offline and understood that he was ok with printing out the Klass*, but did not like to have them stored in the ClassLoaderStats fields. I misunderstood that.
>>
>> So here is an updated version that stores class loader and parent as oops, but prints them as Klass*.
>>
>> http://cr.openjdk.java.net/~sla/8044107/webrev.04/
>
> Thanks for doing these changes.
>
> I think I found a bug in the test:
> 86 Matcher m1 = anonLine.matcher(next);
> 87 m1.matches();
> 88 if (!m1.group(1).equals("1")) {
> 89 throw new Exception("Should have loaded 1 anonymous class, but found : " + m1.group(1));
> 90 }
> 91 checkPositiveInt(m.group(2));
> 92 checkPositiveInt(m.group(3));
>
> Shouldn't line 91 and 92 be looking at m1?
Yes, they should! I fixed that and the test still passes.
>
> Other than that, this looks good.
Thanks!
/Staffan
>
> thanks,
> StefanK
>>
>> Thanks,
>> /Staffan
>>
>>
>>
>>>
>>>> As the code is written right now, it's awkward that we put Klass*s in fields named _parent and _classloader. We usually put oops and CLD*s in fields that are named that way.
>>>
>>> I can change the names of the fields. Suggestions?
>>>
>>>>
>>>> The following code:
>>>>
>>>> 144 // It does not exist in our table - add it
>>>> 145 ClassLoaderStats* cls = new ClassLoaderStats();
>>>> 146 cls->_classloader = cl->klass();
>>>> 147 oop parent = java_lang_ClassLoader::parent(cl);
>>>> 148 if (parent != NULL) {
>>>> 149 cls->_parent = parent->klass();
>>>> 150 }
>>>>
>>>> could be condensed down to:
>>>>
>>>> 144 // It does not exist in our table - add it
>>>> 145 ClassLoaderStats* cls = new ClassLoaderStats();
>>>> 146 cls->_classloader = cl
>>>> 147 cls->_parent = java_lang_ClassLoader::parent(cl);
>>>>
>>>> or even:
>>>>
>>>> 144 // It does not exist in our table - add it
>>>> 145 ClassLoaderStats* cls = new ClassLoaderStats(cl, java_lang_ClassLoader::parent(cl));
>>>>
>>>>
>>>> and
>>>>
>>>> 63 cls->_classloader = (cl == NULL ? NULL : cl->klass());
>>>> 64 if (cl != NULL) {
>>>> 65 oop parent = java_lang_ClassLoader::parent(cl);
>>>> 66 if (parent != NULL) {
>>>> 67 cls->_parent = parent->klass();
>>>> 68 addEmptyParents(parent);
>>>> 69 }
>>>> 70 }
>>>>
>>>> would be come:
>>>>
>>>> 63 cls->_classloader = cl;
>>>> 64 if (cl != NULL) {
>>>> 65 cls->_parent = java_lang_ClassLoader::parent(cl);
>>>> 68 addEmptyParents(cls->_parent);
>>>> 70 }
>>>>
>>>>
>>>>> * The id of the ClassLoader?s parent ClassLoader.
>>>>> * The pointer to the ClassLoaderData structure in the VM. This can be useful for debugging.
>>>>> * The number of classes loaded by the ClassLoader.
>>>>> * The total size of all allocated metaspace chunks for the ClassLoader.
>>>>> * The total size of all allocated metaspace blocks for the ClassLoader.
>>>>>
>>>>> If there are anonymous classes (invokedynamic classes) attributed to the ClassLoader, the following additional information is listed:
>>>>> * The number of anonymous classes loaded by the ClassLoader.
>>>>> * The total size of all allocated metaspace chunks for anonymous classes in the ClassLoader.
>>>>> * The total size of all allocated metaspace blocks for anonymous classes in the ClassLoader.
>>>>>
>>>>> The information is gathered during a safe point to guarantee that the data structures are consistent.
>>>>>
>>>>> I have added a small test and have run this through jprt. A CCC request has been filed.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~sla/8044107/webrev.00/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044107
>>>>>
>>>>> Example output:
>>>>>
>>>>> ClassLoader Parent CLData* Classes ChunkSz BlockSz Type
>>>>
>>>> We usually say ClassLoaderData or CLD in the code, but never CLData. Could this be changed to CLD* or CLD? I guess ClassLoaderData would be too long. Erik also had a suggestion on a more user-friendly name, I'm fine with that as well.
>>>
>>> Changed it to CLD*.
>>>
>>>>
>>>>> 0x00000007c002d908 0x0000000000000000 0x0000000000000000 0 0 0 sun.misc.Launcher$ExtClassLoader
>>>>> 0x0000000000000000 0x0000000000000000 0x00007fb239c08de0 761 4694016 4241312 <boot classloader>
>>>>> 37 75776 50928 + invokedynamic classes
>>>>> 0x00000007c0061028 0x00000007c0036878 0x00007fb239c2de60 1 6144 1976 ClassLoaderStatsTest$DummyClassLoader
>>>>> 1 2048 1288 + invokedynamic classes
>>>>> 0x00000007c0036878 0x00000007c002d908 0x00007fb239e10fc0 8 88064 31544 sun.misc.Launcher$AppClassLoader
>>>>> Total = 4 808 4866048 4327048
>>>>> ChunkSz: Total size of all allocated metaspace chunks
>>>>> BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)
>>>>
>>>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.hpp.html
>>>>
>>>> Is there a reason why these are intx instead of uintx?
>>>>
>>>> 113 intx _total_loaders;
>>>> 114 intx _total_classes;
>>>
>>> Changed to uintx.
>>>
>>>>
>>>>
>>>> Would you mind changing the name of _classloader to _class_loader?
>>>>
>>>> 69 class ClassLoaderStats : public ResourceObj {
>>>> 70 public:
>>>> 71 ClassLoaderData* _cld;
>>>> 72 Klass* _classloader;
>>>
>>> Fixed.
>>>
>>>>
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/src/share/vm/classfile/classLoaderStats.cpp.html
>>>>
>>>> There's a couple of usages of SSIZE_FORMAT_W where I think you should be using SIZE_FORMAT_W
>>>
>>> Fixed.
>>>
>>>>
>>>>
>>>> At some point it would be nice to have an option to be able to list the usages of all individual anonymous class loaders.
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~sla/8044107/webrev.02/test/serviceability/dcmd/ClassLoaderStatsTest.java.html
>>>>
>>>> I don't know if this is a common style in our testing, but I often read test code without the aid of an IDE so import statements with *s make it harder for me to understand where imported classes come from:
>>>>
>>>> 31 import java.nio.*;
>>>> 32 import java.nio.channels.*;
>>>> 33 import java.io.*;
>>>> 34 import java.util.regex.Matcher;
>>>> 35 import java.util.regex.Pattern;
>>>
>>> I agree that this is sloppy. Fixed.
>>>
>>> updated webrev is here: http://cr.openjdk.java.net/~sla/8044107/webrev.03/
>>>
>>> Thanks,
>>> /Staffan
>>>
>>>>
>>>>
>>>> thanks,
>>>> StefanK
>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>
>
From albert.noll at oracle.com Wed Jun 4 09:01:07 2014
From: albert.noll at oracle.com (Albert)
Date: Wed, 04 Jun 2014 11:01:07 +0200
Subject: [8u20] RFR(S): 8011646 : SEGV in compiled code with loop
predication
In-Reply-To: <538EAE4A.2060302@oracle.com>
References: <538EA42C.4000601@oracle.com> <538EAE4A.2060302@oracle.com>
Message-ID: <538EE053.4000107@oracle.com>
Indeed :-)
Thanks for the review.
Best,
Albert
On 06/04/2014 07:27 AM, Vladimir Kozlov wrote:
> Looks good.
>
> You are lucky that is was pushed into jdk9 before 8034812 changes :)
>
> Vladimir
>
> On 6/3/14 9:44 PM, Albert wrote:
>> Hi,
>> I would like to request a 8u20 backport of JDK-8011646.
>>
>> The changes were pushed to 9 on 2014-05-30. Nightly testing showed no
>> problems.
>> The changes applied to 8u20 without conflicts.
>>
>> Master bug: https://bugs.openjdk.java.net/browse/JDK-8011646
>> Webrev: http://cr.openjdk.java.net/~anoll/8011646/webrev.00/
>> Changeset:
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/774578bd0cb4
>>
>> Thanks,
>> Albert
>>
From staffan.larsen at oracle.com Wed Jun 4 13:54:39 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 4 Jun 2014 15:54:39 +0200
Subject: RFR: 8044797 Building with clang gives: fatal error: file '...' has
been modified since the precompiled header was built
Message-ID: <FCC688CB-C65B-4014-8D9E-610A68A4A981@oracle.com>
When building with clang and changing a file that is part of the precompiled header, you can get:
fatal error: file '/Users/staffan/mercurial/jdk9-hs-rt/hotspot/src/share/vm/runtime/thread.hpp' has been modified since the precompiled header was built
clang behaves differently than gcc here.
Example with clang:
$ ls
test.h
$ cat test.h
#include <stdio.h>
$ clang -x c-header -include test.h test.h -o test.h.pch
$ touch test.h
$ clang -x c-header -include test.h test.h -o test.h.pch
fatal error: file '/Users/staffan/tmp/pch/test.h' has been modified since the precompiled header was built
1 error generated.
Same with gcc:
$ ls
test.h
$ cat test.h
#include <stdio.h>
$ gcc -x c-header -include test.h test.h -o test.h.pch
$ touch test.h
$ gcc -x c-header -include test.h test.h -o test.h.pch
The proposed fix is to delete the .pch file before calling clang or gcc.
diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
--- a/make/bsd/makefiles/vm.make
+++ b/make/bsd/makefiles/vm.make
@@ -295,6 +295,7 @@
$(PRECOMPILED_HEADER):
$(QUIETLY) echo Generating precompiled header $@
$(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
+ $(QUIETLY) rm -f $@
$(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
# making the library:
Thanks,
/Staffan
From goetz.lindenmaier at sap.com Wed Jun 4 13:59:02 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 4 Jun 2014 13:59:02 +0000
Subject: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
Hi,
I would like to do another change cleaning up the includes of
.inline.hpp files from the os_cpu directories.
Please review and test this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
This change improves the usage of the umbrella header atomic.inline.hpp.
It removes includes of this header in files where it's not needed,
and adds it in all .cpp and .inline.hpp files where a method of
Atomic declared 'inline' is used.
Also, the change moves some calls to such methods from .hpp files to
.inline.hpp files. In case of ASSERT code it moves the calls
to .cpp files.
A row of headers still contain calls to inline methods of Atomic,
which I don't want to move as no appropriate .inline.hpp file is existing:
src/share/vm/compiler/compileBroker.hpp
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
src/share/vm/gc_implementation/g1/g1StringDedup.hpp
src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
src/share/vm/memory/specialized_oop_closures.hpp
src/share/vm/oops/methodData.hpp
src/share/vm/runtime/safepoint.hpp
src/share/vm/services/lowMemoryDetector.hpp
src/share/vm/services/memTracker.hpp
src/share/vm/utilities/taskqueue.hpp
I compiled and tested this without precompiled headers on
linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
in opt, dbg and fastdbg versions.
Best regards,
Goetz.
From bengt.rutisson at oracle.com Wed Jun 4 15:06:06 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 04 Jun 2014 17:06:06 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <2198629.dbW8eWbo0l@ehelin-desktop>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com>
<537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop>
Message-ID: <538F35DE.1040802@oracle.com>
Hi Erik,
On 5/28/14 2:29 PM, Erik Helin wrote:
> Hi Bengt,
>
> just a first quick general comment: would it make sense for GCId to be
> in its own file or class, so the GC logging don't have to depend on
> the GC trace framework?
Good point.
Here is an updated webrev where I separeted out GCId to its own file:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
Here's just the diff compared to the earlier version:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
Jesper, the updated webrev also contains the spelling mistake you
noticed. Thanks for catching that!
Bengt
>
> Thanks,
> Erik
>
> On Friday 23 May 2014 07.00.44 Bengt Rutisson wrote:
>> Hi Jesper and everyone else,
>>
>> After explaining the problem with GenCollectedHeap in my last email I
>> realized that a different approach would be to just assume that the next
>> GC id will be the right one when we start the logging before we have
>> incremented the GC id. I think that is a nicer way of doing it than
>> "wasting" a GC id as I did before.
>>
>> Here's an updated webrev with that changed:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01/
>>
>> Here's the diff compared to the last webrev:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.00-01-diff/
>>
>> Thanks,
>> Bengt
>>
>> On 5/22/14 9:40 AM, Bengt Rutisson wrote:
>>> Hi Jesper,
>>>
>>> On 5/21/14 7:44 PM, Jesper Wilhelmsson wrote:
>>>> Hi Bengt,
>>>>
>>>> Good change! Thanks for doing this!
>>> Thanks for looking at it.
>>>
>>>> A few thoughts:
>>>>
>>>> * There are a few places that passes both a GCTimer and now a GCId.
>>>> Would it make sense to pass an info-object of some kind that contains
>>>> misc info that is used for logging/tracing? I'm not suggesting that
>>>> you should implement that in this change, just a thought for the
> future.
>>> Yes, I think that may be a good future cleanup to do. But would be
>>> good as a separate change, just as you point out.
>>>
>>>> * In genCollectdHeap.cpp you increase the gc id only if
>>>> PrintGCDetails is enabled. I assume this is the only place where a gc
>>>> id is used when running collectors that use
>>>> GenCollectedHeap::do_collection(). If not, the id created and used in
>>>> other places would be different depending on if PrintGCDetails was
>>>> enabled or not.
>>> Yes, this is a work around for the strange way the logging for
>>> GenCollectedHeap works. We do completely different timing and logging
>>> for PrintGC and PrintGCDetails. That the logging is different is just
>>> strange. That the the timing is different is in my opinion a bug. The
>>> pause time reported is shorter if you run with PrintGC than if you run
>>> with PrintGCDetails.
>>>
>>> This mostly affect CMS. The logging for CMS has several other issues
>>> as well. I added one comment about that in the bug report. So, I think
>>> it would be good to give the CMS logging an overhaul, but that should
>>> definitely be a separate change :) And maybe we should hold off with
>>> that until the unified logging framework is in place.
>>>
>>>> Anyway, looks good!
>>> Thanks!
>>>
>>> Bengt
>>>
>>>> Ship it!
>>>> /Jesper
>>>>
>>>> Bengt Rutisson skrev 21/5/14 11:31:
>>>>> Hi everyone,
>>>>>
>>>>> Can I have some reviews for this patch:
>>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.00/
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8043607
>>>>>
>>>>> This is mostly a GC change but I am sending it to the broader list
>>>>> since I added
>>>>> a method to ostream.hpp/cpp. We had this code duplicated in many
>>>>> places in the
>>>>> GC code:
>>>>>
>>>>> gclog_or_tty->date_stamp(PrintGCDateStamps);
>>>>> gclog_or_tty->stamp(PrintGCTimeStamps);
>>>>>
>>>>> And with my patch I had to add one more section to this code
>>>>> duplication.
>>>>> Instead I wrapped all three calls in a method called gclog_stamp().
>>>>> It is a bit
>>>>> hard to know where to place that method. ostream seems like the
>>>>> wrong place for
>>>>> GC specific code, but there is already lots of GC specific code
>>>>> there and even
>>>>> gclog_or_tty is declared there. So I added the method there for now:
>>>>>
>>>>> void outputStream::gclog_stamp(uint gc_id) {
>>>>>
>>>>> date_stamp(PrintGCDateStamps);
>>>>> stamp(PrintGCTimeStamps);
>>>>> if (PrintGCID) {
>>>>>
>>>>> print("#%u: ", gc_id);
>>>>>
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> Other than that this is a pure GC change.
>>>>>
>>>>>
>>>>> Background:
>>>>>
>>>>> With event based tracing we introduced a GC id field on all GC
>>>>> events. This id
>>>>> is a constantly increasing number associated with each GC. I figured
>>>>> we can use
>>>>> the this GC id as a decoration for the HotSpot GC logging similarly
>>>>> to what we
>>>>> do with PrintGCTimeStamps and PrintGCDateStamps.
>>>>>
>>>>> A nice side effect of this is that it will make it easy to map an
>>>>> event in the
>>>>> event tracing to an entry in the GC log. Currently this is
>>>>> impossible to do
>>>>> deterministically since the logging and event tracing use different
>>>>> timing.
>>>>>
>>>>> I propose to add a flag called PrintGCID. Here's an example log
>>>>> entry for GC
>>>>> number 4 running with -XX:+PrintGCID:
>>>>>
>>>>> #4: [GC pause (G1 Evacuation Pause) (young) 185M->212M(502M),
>>>>> 0,2373420 secs]
>>>>>
>>>>> It is a decoration similar to the timestamps. Here's what it looks
>>>>> like if you
>>>>> add -XX:+PrintGCTimeStamps:
>>>>>
>>>>> 3,921: #4: [GC pause (G1 Evacuation Pause) (young)
>>>>> 185M->212M(502M), 0,2373420
>>>>> secs]
>>>>>
>>>>> And here's what it will look like if you add -XX:+PrintGCDateStamps:
>>>>>
>>>>> 2014-05-09T13:03:59.384+0200: 3,921: #4: [GC pause (G1 Evacuation
>>>>> Pause)
>>>>> (young) 185M->212M(502M), 0,2373420 secs]
>>>>>
>>>>>
>>>>> Here's a little longer example running ParallelGC:
>>>>>
>>>>> #0: [GC (Allocation Failure) 129024K->2980K(493056K), 0,1050244
> secs]
>>>>> #1: [GC (Allocation Failure) 132004K->3731K(622080K), 0,0389474
> secs]
>>>>> #2: [GC (Allocation Failure) 261779K->27153K(622080K), 0,2057294
> secs]
>>>>> #3: [GC (Allocation Failure) 285201K->224350K(880128K), 0,2410144
>>>>> secs]
>>>>> #4: [Full GC (Ergonomics) 224350K->219198K(1154560K), 2,7104481
> secs]
>>>>> #5: [GC (Allocation Failure) 735294K->638073K(863744K), 0,7707819
>>>>> secs]
>>>>>
>>>>> Note that for the concurrent GCs this gives a good way of seeing the
>>>>> concurrent
>>>>> action. Here is a G1 example:
>>>>>
>>>>> #0: [GC pause (G1 Evacuation Pause) (young) 24M->2881K(502M),
>>>>> 0,0383157 secs]
>>>>> #1: [GC pause (G1 Evacuation Pause) (young) 48M->4745K(502M),
>>>>> 0,0412220 secs]
>>>>> #2: [GC pause (G1 Evacuation Pause) (young) 136M->9618K(502M),
>>>>> 0,0426144 secs]
>>>>> #3: [GC pause (G1 Evacuation Pause) (young) 248M->143M(502M),
>>>>> 0,1467633 secs]
>>>>> #4: [GC pause (G1 Evacuation Pause) (young) 210M->199M(502M),
>>>>> 0,1627465 secs]
>>>>> #5: [GC pause (G1 Evacuation Pause) (young) 213M->235M(502M),
>>>>> 0,2376728 secs]
>>>>> #6: [GC pause (G1 Evacuation Pause) (young) (initial-mark)
>>>>> 255M->269M(1004M),
>>>>> 0,2623779 secs]
>>>>> #7: [GC concurrent-root-region-scan-start]
>>>>> #7: [GC concurrent-root-region-scan-end, 0,0158488 secs]
>>>>> #7: [GC concurrent-mark-start]
>>>>> #8: [GC pause (G1 Evacuation Pause) (young) 315M->330M(2008M),
>>>>> 0,3007405 secs]
>>>>> #9: [GC pause (G1 Evacuation Pause) (young) 422M->418M(3212M),
>>>>> 0,4063937 secs]
>>>>> #10: [GC pause (G1 Evacuation Pause) (young) 564M->572M(4176M),
>>>>> 0,7500609 secs]
>>>>> #11: [GC pause (G1 Evacuation Pause) (young) 760M->756M(4946M),
>>>>> 1,5464884 secs]
>>>>> #7: [GC concurrent-mark-end, 3,9464599 secs]
>>>>> #7: [GC remark, 0,0240462 secs]
>>>>> #7: [GC cleanup 801M->800M(4946M), 0,0108146 secs]
>>>>> #7: [GC concurrent-cleanup-start]
>>>>> #7: [GC concurrent-cleanup-end, 0,0000228 secs]
>>>>> #12: [GC pause (G1 Evacuation Pause) (young) 977M->978M(5562M),
>>>>> 2,2464423 secs]
>>>>>
>>>>> Notice how the complete concurrent cycle is decorated with id #7.
>>>>> That makes it
>>>>> possible to follow the concurrent work more easily and grep it out
> etc.
>>>>>
>>>>> Here's a similar thing for CMS where the concurrent cycle #22 has a
>>>>> young GC #23
>>>>> in the middle of it:
>>>>>
>>>>> #21: [GC (Allocation Failure) 1621551K->1107977K(2395632K),
>>>>> 1,4558792 secs]
>>>>> #22: [GC (CMS Initial Mark) 1336515K(2452584K), 0,1107938 secs]
>>>>> #23: [GC (Allocation Failure) 1768969K->1184500K(2452584K),
>>>>> 0,7909961 secs]
>>>>> #22: [GC (CMS Final Remark) 1304871K(2452584K), 0,2353840 secs]
>>>>>
>>>>>
>>>>> I think this is very helpful information to have, so I would like to
>>>>> push this
>>>>> with the new flag PrintGCID as true by default. I'm sure some
>>>>> parsers will
>>>>> break, but it is an easy work around to run with -XX:-PrintGCID to
>>>>> get the old
>>>>> format. It should even be pretty easy to do post processing on a log
>>>>> file to
>>>>> remove the GC id information. Having it on by default makes it
>>>>> possible for us
>>>>> to use this information and in particular be able to map it to the
>>>>> JFR events we
>>>>> see in MissionControl.
>>>>>
>>>>> I would also like to backport this to 8u40, but in that case with
>>>>> the default
>>>>> value of PrintGCID as false.
>>>>>
>>>>> Thanks,
>>>>> Bengt
From dmitry.fazunenko at oracle.com Wed Jun 4 16:11:42 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 04 Jun 2014 20:11:42 +0400
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <537E1EC3.9080607@oracle.com>
References: <537E1EC3.9080607@oracle.com>
Message-ID: <538F453E.6010105@oracle.com>
Hello,
This fix introduces new jtreg groups to allow not running tests which
could conflict because of GC.
Please note, this solution is temporary for 2-3 months, unless jtreg
starts support the @requires tag
(CODETOOLS-7900307) <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
The change itself doesn't affect anything, it just allows to run group
of tests which doesn't require a specific gc.
Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
Webrev: http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
Testing:
I ran all 4 ":applicable_XXXgc" groups with the corresponding GC and saw
only known issues not related to the conflict of flags.
Thanks,
Dima
From vladimir.kozlov at oracle.com Wed Jun 4 20:36:29 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 04 Jun 2014 13:36:29 -0700
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
Message-ID: <538F834D.3090502@oracle.com>
Looks good to me.
Vladimir
On 6/4/14 6:59 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to do another change cleaning up the includes of
> .inline.hpp files from the os_cpu directories.
>
> Please review and test this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
>
> This change improves the usage of the umbrella header atomic.inline.hpp.
> It removes includes of this header in files where it's not needed,
> and adds it in all .cpp and .inline.hpp files where a method of
> Atomic declared 'inline' is used.
>
> Also, the change moves some calls to such methods from .hpp files to
> .inline.hpp files. In case of ASSERT code it moves the calls
> to .cpp files.
>
> A row of headers still contain calls to inline methods of Atomic,
> which I don't want to move as no appropriate .inline.hpp file is existing:
>
> src/share/vm/compiler/compileBroker.hpp
> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
> src/share/vm/memory/specialized_oop_closures.hpp
> src/share/vm/oops/methodData.hpp
> src/share/vm/runtime/safepoint.hpp
> src/share/vm/services/lowMemoryDetector.hpp
> src/share/vm/services/memTracker.hpp
> src/share/vm/utilities/taskqueue.hpp
>
> I compiled and tested this without precompiled headers on
> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
> in opt, dbg and fastdbg versions.
>
> Best regards,
> Goetz.
>
From david.holmes at oracle.com Wed Jun 4 22:54:29 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 05 Jun 2014 08:54:29 +1000
Subject: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ?
Message-ID: <538FA3A5.3020504@oracle.com>
SUPPORTS_NATIVE_CX8 is used by platforms with full 64-bit CAS and
atomics capability to elide the lock-based Unsafe jlong atomic update
methods and avoid a runtime VM_Version::supports_cx8() check. I just
noticed this isn't set for PPC64. Can I assume that is just an
oversight? I have some changes to the lock-based code in the pipeline
and can update the PPC64 code at the same time if desired.
Thanks,
David
From goetz.lindenmaier at sap.com Thu Jun 5 06:54:49 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 5 Jun 2014 06:54:49 +0000
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <538F834D.3090502@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
<538F834D.3090502@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC6BAE@DEWDFEMB12A.global.corp.sap>
Thanks, Vladimir!
Best regards,
Goetz.
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
Sent: Mittwoch, 4. Juni 2014 22:36
To: hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
Looks good to me.
Vladimir
On 6/4/14 6:59 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to do another change cleaning up the includes of
> .inline.hpp files from the os_cpu directories.
>
> Please review and test this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
>
> This change improves the usage of the umbrella header atomic.inline.hpp.
> It removes includes of this header in files where it's not needed,
> and adds it in all .cpp and .inline.hpp files where a method of
> Atomic declared 'inline' is used.
>
> Also, the change moves some calls to such methods from .hpp files to
> .inline.hpp files. In case of ASSERT code it moves the calls
> to .cpp files.
>
> A row of headers still contain calls to inline methods of Atomic,
> which I don't want to move as no appropriate .inline.hpp file is existing:
>
> src/share/vm/compiler/compileBroker.hpp
> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
> src/share/vm/memory/specialized_oop_closures.hpp
> src/share/vm/oops/methodData.hpp
> src/share/vm/runtime/safepoint.hpp
> src/share/vm/services/lowMemoryDetector.hpp
> src/share/vm/services/memTracker.hpp
> src/share/vm/utilities/taskqueue.hpp
>
> I compiled and tested this without precompiled headers on
> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
> in opt, dbg and fastdbg versions.
>
> Best regards,
> Goetz.
>
From goetz.lindenmaier at sap.com Thu Jun 5 07:06:28 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 5 Jun 2014 07:06:28 +0000
Subject: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ?
In-Reply-To: <538FA3A5.3020504@oracle.com>
References: <538FA3A5.3020504@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC6BD4@DEWDFEMB12A.global.corp.sap>
Hi David,
thanks for spotting this! Yes, this should be set. We also set it
in our internal VM, somehow it got lost in the port.
It would be great if you could fix this along with your change.
Best regards,
Goetz.
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Donnerstag, 5. Juni 2014 00:54
To: ppc-aix-port-dev at openjdk.java.net
Cc: hotspot-dev developers
Subject: PPC64 doesn't define SUPPORTS_NATIVE_CX8 ?
SUPPORTS_NATIVE_CX8 is used by platforms with full 64-bit CAS and
atomics capability to elide the lock-based Unsafe jlong atomic update
methods and avoid a runtime VM_Version::supports_cx8() check. I just
noticed this isn't set for PPC64. Can I assume that is just an
oversight? I have some changes to the lock-based code in the pipeline
and can update the PPC64 code at the same time if desired.
Thanks,
David
From stefan.karlsson at oracle.com Thu Jun 5 08:38:22 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 05 Jun 2014 10:38:22 +0200
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
Message-ID: <53902C7E.5010108@oracle.com>
Hi Goetz,
Thanks again for cleaning up the include files.
On 2014-06-04 15:59, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to do another change cleaning up the includes of
> .inline.hpp files from the os_cpu directories.
>
> Please review and test this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.hpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.cpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupQueue.cpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp.udiff.html
I think it would be good to move the Atomic calls out from the
g1StringDedup.hpp to g1StringDedup.cpp. I talked to Per, the author of
StringDedup, and he would be fine with that move.
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.frames.html
32 #if INCLUDE_ALL_GCS
33 #include "gc_implementation/g1/g1StringDedup.hpp"
34 #include "gc_implementation/parallelScavenge/psParallelCompact.hpp"
35 #include "runtime/atomic.inline.hpp"
36 #endif // INCLUDE_ALL_GCS
Why was this include added? Was it becuase g1StringDedup.hpp was added?
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/mutableSpace.cpp.frames.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/oop.pcgc.inline.hpp.frames.html
25 #include "precompiled.hpp"
26 #include "utilities/macros.hpp"
27 #if INCLUDE_ALL_GCS
28 #include "gc_implementation/shared/mutableSpace.hpp"
29 #include "gc_implementation/shared/spaceDecorator.hpp"
30 #include "oops/oop.inline.hpp"
31 #include "runtime/safepoint.hpp"
32 #include "runtime/thread.hpp"
33 #endif // INCLUDE_ALL_GCS
34 #include "runtime/atomic.inline.hpp"
Could you place the new includes together with the includes before the
INCLUDE_ALL_GCS block?
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.hpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.inline.hpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/runtime/safepoint.cpp.udiff.html
+ inline static void increment_debug_jni_lock_count();
+ inline static void decrement_debug_jni_lock_count();
This is debugging code, so it would be better to move it to the .cpp file.
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/compiledICHolder.hpp.udiff.html
54 #ifdef ASSERT
55 CompiledICHolder(Method* method, Klass* klass);
56 #else
57 CompiledICHolder(Method* method, Klass* klass)
58 : _holder_method(method), _holder_klass(klass) {};
59 #endif
60
61 ~CompiledICHolder() NOT_DEBUG_RETURN;
This is a lot of noise just to get rid of a call to the the
CompiledICHolder constructor in product builds. Is it really worth it?
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/precompiled/precompiled.hpp.udiff.html
# include "runtime/atomic.hpp"
+# include "runtime/atomic.inline.hpp"
I still think this is a bad idea. It will just make it more likely that
someone building with precompiled headers will forget to include
atomic.inline.hpp, and we would have to clean it up later when we found
out that it breaks some platform outside of Oracle's test matrix.
thanks,
StefanK
>
> This change improves the usage of the umbrella header atomic.inline.hpp.
> It removes includes of this header in files where it's not needed,
> and adds it in all .cpp and .inline.hpp files where a method of
> Atomic declared 'inline' is used.
>
> Also, the change moves some calls to such methods from .hpp files to
> .inline.hpp files. In case of ASSERT code it moves the calls
> to .cpp files.
>
> A row of headers still contain calls to inline methods of Atomic,
> which I don't want to move as no appropriate .inline.hpp file is existing:
>
> src/share/vm/compiler/compileBroker.hpp
> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
> src/share/vm/memory/specialized_oop_closures.hpp
> src/share/vm/oops/methodData.hpp
> src/share/vm/runtime/safepoint.hpp
> src/share/vm/services/lowMemoryDetector.hpp
> src/share/vm/services/memTracker.hpp
> src/share/vm/utilities/taskqueue.hpp
>
> I compiled and tested this without precompiled headers on
> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
> in opt, dbg and fastdbg versions.
>
> Best regards,
> Goetz.
From erik.helin at oracle.com Thu Jun 5 09:43:39 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 05 Jun 2014 11:43:39 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar to
PrintGCTimeStamps
In-Reply-To: <538F35DE.1040802@oracle.com>
References: <537C7264.70200@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop>
<538F35DE.1040802@oracle.com>
Message-ID: <2606893.zJ7FtGnJkx@ehelin-desktop>
Hi Bengt,
On Wednesday 04 June 2014 17.06.06 Bengt Rutisson wrote:
> Hi Erik,
>
> On 5/28/14 2:29 PM, Erik Helin wrote:
> > Hi Bengt,
> >
> > just a first quick general comment: would it make sense for GCId to be
> > in its own file or class, so the GC logging don't have to depend on
> > the GC trace framework?
>
> Good point.
>
> Here is an updated webrev where I separeted out GCId to its own file:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
>
> Here's just the diff compared to the earlier version:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
Looks much better! A couple of suggestions:
- How about shortening the names a little bit for the static methods?
- GCId::create()
- GCId::peek()
Since the methods are static, we must always prefix the methods with
GCId, so this will be as explicit as the current version.
- Instead of using the global static variable UNSET_GCID, what about
having a third static method, undefined():
- public static GCId GCId::undefined()
We could also implement operator== and operator!= so that comparing
two GCIds becomes a little easier.
What do you think?
Thanks,
Erik
> Jesper, the updated webrev also contains the spelling mistake you
> noticed. Thanks for catching that!
>
> Bengt
>
> > Thanks,
> > Erik
> >
> > On Friday 23 May 2014 07.00.44 Bengt Rutisson wrote:
> >> Hi Jesper and everyone else,
> >>
> >> After explaining the problem with GenCollectedHeap in my last email I
> >> realized that a different approach would be to just assume that the next
> >> GC id will be the right one when we start the logging before we have
> >> incremented the GC id. I think that is a nicer way of doing it than
> >> "wasting" a GC id as I did before.
> >>
> >> Here's an updated webrev with that changed:
> >> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01/
> >>
> >> Here's the diff compared to the last webrev:
> >> http://cr.openjdk.java.net/~brutisso/8043607/webrev.00-01-diff/
> >>
> >> Thanks,
> >> Bengt
> >>
> >> On 5/22/14 9:40 AM, Bengt Rutisson wrote:
> >>> Hi Jesper,
> >>>
> >>> On 5/21/14 7:44 PM, Jesper Wilhelmsson wrote:
> >>>> Hi Bengt,
> >>>>
> >>>> Good change! Thanks for doing this!
> >>>
> >>> Thanks for looking at it.
> >>>
> >>>> A few thoughts:
> >>>>
> >>>> * There are a few places that passes both a GCTimer and now a GCId.
> >>>> Would it make sense to pass an info-object of some kind that contains
> >>>> misc info that is used for logging/tracing? I'm not suggesting that
> >>>> you should implement that in this change, just a thought for the
> >
> > future.
> >
> >>> Yes, I think that may be a good future cleanup to do. But would be
> >>> good as a separate change, just as you point out.
> >>>
> >>>> * In genCollectdHeap.cpp you increase the gc id only if
> >>>> PrintGCDetails is enabled. I assume this is the only place where a gc
> >>>> id is used when running collectors that use
> >>>> GenCollectedHeap::do_collection(). If not, the id created and used in
> >>>> other places would be different depending on if PrintGCDetails was
> >>>> enabled or not.
> >>>
> >>> Yes, this is a work around for the strange way the logging for
> >>> GenCollectedHeap works. We do completely different timing and logging
> >>> for PrintGC and PrintGCDetails. That the logging is different is just
> >>> strange. That the the timing is different is in my opinion a bug. The
> >>> pause time reported is shorter if you run with PrintGC than if you run
> >>> with PrintGCDetails.
> >>>
> >>> This mostly affect CMS. The logging for CMS has several other issues
> >>> as well. I added one comment about that in the bug report. So, I think
> >>> it would be good to give the CMS logging an overhaul, but that should
> >>> definitely be a separate change :) And maybe we should hold off with
> >>> that until the unified logging framework is in place.
> >>>
> >>>> Anyway, looks good!
> >>>
> >>> Thanks!
> >>>
> >>> Bengt
> >>>
> >>>> Ship it!
> >>>> /Jesper
> >>>>
> >>>> Bengt Rutisson skrev 21/5/14 11:31:
> >>>>> Hi everyone,
> >>>>>
> >>>>> Can I have some reviews for this patch:
> >>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.00/
> >>>>>
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8043607
> >>>>>
> >>>>> This is mostly a GC change but I am sending it to the broader list
> >>>>> since I added
> >>>>> a method to ostream.hpp/cpp. We had this code duplicated in many
> >>>>> places in the
> >>>>> GC code:
> >>>>>
> >>>>> gclog_or_tty->date_stamp(PrintGCDateStamps);
> >>>>> gclog_or_tty->stamp(PrintGCTimeStamps);
> >>>>>
> >>>>> And with my patch I had to add one more section to this code
> >>>>> duplication.
> >>>>> Instead I wrapped all three calls in a method called gclog_stamp().
> >>>>> It is a bit
> >>>>> hard to know where to place that method. ostream seems like the
> >>>>> wrong place for
> >>>>> GC specific code, but there is already lots of GC specific code
> >>>>> there and even
> >>>>> gclog_or_tty is declared there. So I added the method there for now:
> >>>>>
> >>>>> void outputStream::gclog_stamp(uint gc_id) {
> >>>>>
> >>>>> date_stamp(PrintGCDateStamps);
> >>>>> stamp(PrintGCTimeStamps);
> >>>>> if (PrintGCID) {
> >>>>>
> >>>>> print("#%u: ", gc_id);
> >>>>>
> >>>>> }
> >>>>>
> >>>>> }
> >>>>>
> >>>>> Other than that this is a pure GC change.
> >>>>>
> >>>>>
> >>>>> Background:
> >>>>>
> >>>>> With event based tracing we introduced a GC id field on all GC
> >>>>> events. This id
> >>>>> is a constantly increasing number associated with each GC. I figured
> >>>>> we can use
> >>>>> the this GC id as a decoration for the HotSpot GC logging similarly
> >>>>> to what we
> >>>>> do with PrintGCTimeStamps and PrintGCDateStamps.
> >>>>>
> >>>>> A nice side effect of this is that it will make it easy to map an
> >>>>> event in the
> >>>>> event tracing to an entry in the GC log. Currently this is
> >>>>> impossible to do
> >>>>> deterministically since the logging and event tracing use different
> >>>>> timing.
> >>>>>
> >>>>> I propose to add a flag called PrintGCID. Here's an example log
> >>>>> entry for GC
> >>>>> number 4 running with -XX:+PrintGCID:
> >>>>>
> >>>>> #4: [GC pause (G1 Evacuation Pause) (young) 185M->212M(502M),
> >>>>> 0,2373420 secs]
> >>>>>
> >>>>> It is a decoration similar to the timestamps. Here's what it looks
> >>>>> like if you
> >>>>> add -XX:+PrintGCTimeStamps:
> >>>>>
> >>>>> 3,921: #4: [GC pause (G1 Evacuation Pause) (young)
> >>>>> 185M->212M(502M), 0,2373420
> >>>>> secs]
> >>>>>
> >>>>> And here's what it will look like if you add -XX:+PrintGCDateStamps:
> >>>>>
> >>>>> 2014-05-09T13:03:59.384+0200: 3,921: #4: [GC pause (G1 Evacuation
> >>>>> Pause)
> >>>>> (young) 185M->212M(502M), 0,2373420 secs]
> >>>>>
> >>>>>
> >>>>> Here's a little longer example running ParallelGC:
> >>>>>
> >>>>> #0: [GC (Allocation Failure) 129024K->2980K(493056K), 0,1050244
> >
> > secs]
> >
> >>>>> #1: [GC (Allocation Failure) 132004K->3731K(622080K), 0,0389474
> >
> > secs]
> >
> >>>>> #2: [GC (Allocation Failure) 261779K->27153K(622080K), 0,2057294
> >
> > secs]
> >
> >>>>> #3: [GC (Allocation Failure) 285201K->224350K(880128K), 0,2410144
> >>>>> secs]
> >>>>> #4: [Full GC (Ergonomics) 224350K->219198K(1154560K), 2,7104481
> >
> > secs]
> >
> >>>>> #5: [GC (Allocation Failure) 735294K->638073K(863744K), 0,7707819
> >>>>> secs]
> >>>>>
> >>>>> Note that for the concurrent GCs this gives a good way of seeing the
> >>>>> concurrent
> >>>>> action. Here is a G1 example:
> >>>>>
> >>>>> #0: [GC pause (G1 Evacuation Pause) (young) 24M->2881K(502M),
> >>>>> 0,0383157 secs]
> >>>>> #1: [GC pause (G1 Evacuation Pause) (young) 48M->4745K(502M),
> >>>>> 0,0412220 secs]
> >>>>> #2: [GC pause (G1 Evacuation Pause) (young) 136M->9618K(502M),
> >>>>> 0,0426144 secs]
> >>>>> #3: [GC pause (G1 Evacuation Pause) (young) 248M->143M(502M),
> >>>>> 0,1467633 secs]
> >>>>> #4: [GC pause (G1 Evacuation Pause) (young) 210M->199M(502M),
> >>>>> 0,1627465 secs]
> >>>>> #5: [GC pause (G1 Evacuation Pause) (young) 213M->235M(502M),
> >>>>> 0,2376728 secs]
> >>>>> #6: [GC pause (G1 Evacuation Pause) (young) (initial-mark)
> >>>>> 255M->269M(1004M),
> >>>>> 0,2623779 secs]
> >>>>> #7: [GC concurrent-root-region-scan-start]
> >>>>> #7: [GC concurrent-root-region-scan-end, 0,0158488 secs]
> >>>>> #7: [GC concurrent-mark-start]
> >>>>> #8: [GC pause (G1 Evacuation Pause) (young) 315M->330M(2008M),
> >>>>> 0,3007405 secs]
> >>>>> #9: [GC pause (G1 Evacuation Pause) (young) 422M->418M(3212M),
> >>>>> 0,4063937 secs]
> >>>>> #10: [GC pause (G1 Evacuation Pause) (young) 564M->572M(4176M),
> >>>>> 0,7500609 secs]
> >>>>> #11: [GC pause (G1 Evacuation Pause) (young) 760M->756M(4946M),
> >>>>> 1,5464884 secs]
> >>>>> #7: [GC concurrent-mark-end, 3,9464599 secs]
> >>>>> #7: [GC remark, 0,0240462 secs]
> >>>>> #7: [GC cleanup 801M->800M(4946M), 0,0108146 secs]
> >>>>> #7: [GC concurrent-cleanup-start]
> >>>>> #7: [GC concurrent-cleanup-end, 0,0000228 secs]
> >>>>> #12: [GC pause (G1 Evacuation Pause) (young) 977M->978M(5562M),
> >>>>> 2,2464423 secs]
> >>>>>
> >>>>> Notice how the complete concurrent cycle is decorated with id #7.
> >>>>> That makes it
> >>>>> possible to follow the concurrent work more easily and grep it out
> >
> > etc.
> >
> >>>>> Here's a similar thing for CMS where the concurrent cycle #22 has a
> >>>>> young GC #23
> >>>>> in the middle of it:
> >>>>>
> >>>>> #21: [GC (Allocation Failure) 1621551K->1107977K(2395632K),
> >>>>> 1,4558792 secs]
> >>>>> #22: [GC (CMS Initial Mark) 1336515K(2452584K), 0,1107938 secs]
> >>>>> #23: [GC (Allocation Failure) 1768969K->1184500K(2452584K),
> >>>>> 0,7909961 secs]
> >>>>> #22: [GC (CMS Final Remark) 1304871K(2452584K), 0,2353840 secs]
> >>>>>
> >>>>>
> >>>>> I think this is very helpful information to have, so I would like to
> >>>>> push this
> >>>>> with the new flag PrintGCID as true by default. I'm sure some
> >>>>> parsers will
> >>>>> break, but it is an easy work around to run with -XX:-PrintGCID to
> >>>>> get the old
> >>>>> format. It should even be pretty easy to do post processing on a log
> >>>>> file to
> >>>>> remove the GC id information. Having it on by default makes it
> >>>>> possible for us
> >>>>> to use this information and in particular be able to map it to the
> >>>>> JFR events we
> >>>>> see in MissionControl.
> >>>>>
> >>>>> I would also like to backport this to 8u40, but in that case with
> >>>>> the default
> >>>>> value of PrintGCID as false.
> >>>>>
> >>>>> Thanks,
> >>>>> Bengt
From david.holmes at oracle.com Thu Jun 5 11:38:27 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 05 Jun 2014 21:38:27 +1000
Subject: RFR: 8044797 Building with clang gives: fatal error: file '...'
has been modified since the precompiled header was built
In-Reply-To: <FCC688CB-C65B-4014-8D9E-610A68A4A981@oracle.com>
References: <FCC688CB-C65B-4014-8D9E-610A68A4A981@oracle.com>
Message-ID: <539056B3.50500@oracle.com>
On 4/06/2014 11:54 PM, Staffan Larsen wrote:
> When building with clang and changing a file that is part of the precompiled header, you can get:
>
> fatal error: file '/Users/staffan/mercurial/jdk9-hs-rt/hotspot/src/share/vm/runtime/thread.hpp' has been modified since the precompiled header was built
>
> clang behaves differently than gcc here.
You mean clang reports an error when regenerating the pch file? That
seems like a bug to me.
Deleting the file first seems quite reasonable.
Thanks,
David
> Example with clang:
>
> $ ls
> test.h
> $ cat test.h
> #include <stdio.h>
> $ clang -x c-header -include test.h test.h -o test.h.pch
> $ touch test.h
> $ clang -x c-header -include test.h test.h -o test.h.pch
> fatal error: file '/Users/staffan/tmp/pch/test.h' has been modified since the precompiled header was built
> 1 error generated.
>
> Same with gcc:
>
> $ ls
> test.h
> $ cat test.h
> #include <stdio.h>
> $ gcc -x c-header -include test.h test.h -o test.h.pch
> $ touch test.h
> $ gcc -x c-header -include test.h test.h -o test.h.pch
>
>
> The proposed fix is to delete the .pch file before calling clang or gcc.
>
> diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
> --- a/make/bsd/makefiles/vm.make
> +++ b/make/bsd/makefiles/vm.make
> @@ -295,6 +295,7 @@
> $(PRECOMPILED_HEADER):
> $(QUIETLY) echo Generating precompiled header $@
> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
> + $(QUIETLY) rm -f $@
> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>
> # making the library:
>
>
> Thanks,
> /Staffan
>
From bengt.rutisson at oracle.com Thu Jun 5 11:47:01 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 05 Jun 2014 13:47:01 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <2606893.zJ7FtGnJkx@ehelin-desktop>
References: <537C7264.70200@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop>
<538F35DE.1040802@oracle.com> <2606893.zJ7FtGnJkx@ehelin-desktop>
Message-ID: <539058B5.9060703@oracle.com>
Hi Erik,
Good suggestions!
Updated webrev:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.03/
Webrev with only the changes compared to the last one:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.02-03.diff/
Thanks,
Bengt
On 2014-06-05 11:43, Erik Helin wrote:
> Hi Bengt,
>
> On Wednesday 04 June 2014 17.06.06 Bengt Rutisson wrote:
>> Hi Erik,
>>
>> On 5/28/14 2:29 PM, Erik Helin wrote:
>>> Hi Bengt,
>>>
>>> just a first quick general comment: would it make sense for GCId to be
>>> in its own file or class, so the GC logging don't have to depend on
>>> the GC trace framework?
>> Good point.
>>
>> Here is an updated webrev where I separeted out GCId to its own file:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
>>
>> Here's just the diff compared to the earlier version:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
> Looks much better! A couple of suggestions:
>
> - How about shortening the names a little bit for the static methods?
> - GCId::create()
> - GCId::peek()
>
> Since the methods are static, we must always prefix the methods with
> GCId, so this will be as explicit as the current version.
>
> - Instead of using the global static variable UNSET_GCID, what about
> having a third static method, undefined():
> - public static GCId GCId::undefined()
>
> We could also implement operator== and operator!= so that comparing
> two GCIds becomes a little easier.
>
> What do you think?
>
> Thanks,
> Erik
>
>> Jesper, the updated webrev also contains the spelling mistake you
>> noticed. Thanks for catching that!
>>
>> Bengt
>>
>>> Thanks,
>>> Erik
>>>
>>> On Friday 23 May 2014 07.00.44 Bengt Rutisson wrote:
>>>> Hi Jesper and everyone else,
>>>>
>>>> After explaining the problem with GenCollectedHeap in my last email I
>>>> realized that a different approach would be to just assume that the next
>>>> GC id will be the right one when we start the logging before we have
>>>> incremented the GC id. I think that is a nicer way of doing it than
>>>> "wasting" a GC id as I did before.
>>>>
>>>> Here's an updated webrev with that changed:
>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01/
>>>>
>>>> Here's the diff compared to the last webrev:
>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.00-01-diff/
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>> On 5/22/14 9:40 AM, Bengt Rutisson wrote:
>>>>> Hi Jesper,
>>>>>
>>>>> On 5/21/14 7:44 PM, Jesper Wilhelmsson wrote:
>>>>>> Hi Bengt,
>>>>>>
>>>>>> Good change! Thanks for doing this!
>>>>> Thanks for looking at it.
>>>>>
>>>>>> A few thoughts:
>>>>>>
>>>>>> * There are a few places that passes both a GCTimer and now a GCId.
>>>>>> Would it make sense to pass an info-object of some kind that contains
>>>>>> misc info that is used for logging/tracing? I'm not suggesting that
>>>>>> you should implement that in this change, just a thought for the
>>> future.
>>>
>>>>> Yes, I think that may be a good future cleanup to do. But would be
>>>>> good as a separate change, just as you point out.
>>>>>
>>>>>> * In genCollectdHeap.cpp you increase the gc id only if
>>>>>> PrintGCDetails is enabled. I assume this is the only place where a gc
>>>>>> id is used when running collectors that use
>>>>>> GenCollectedHeap::do_collection(). If not, the id created and used in
>>>>>> other places would be different depending on if PrintGCDetails was
>>>>>> enabled or not.
>>>>> Yes, this is a work around for the strange way the logging for
>>>>> GenCollectedHeap works. We do completely different timing and logging
>>>>> for PrintGC and PrintGCDetails. That the logging is different is just
>>>>> strange. That the the timing is different is in my opinion a bug. The
>>>>> pause time reported is shorter if you run with PrintGC than if you run
>>>>> with PrintGCDetails.
>>>>>
>>>>> This mostly affect CMS. The logging for CMS has several other issues
>>>>> as well. I added one comment about that in the bug report. So, I think
>>>>> it would be good to give the CMS logging an overhaul, but that should
>>>>> definitely be a separate change :) And maybe we should hold off with
>>>>> that until the unified logging framework is in place.
>>>>>
>>>>>> Anyway, looks good!
>>>>> Thanks!
>>>>>
>>>>> Bengt
>>>>>
>>>>>> Ship it!
>>>>>> /Jesper
>>>>>>
>>>>>> Bengt Rutisson skrev 21/5/14 11:31:
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Can I have some reviews for this patch:
>>>>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.00/
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043607
>>>>>>>
>>>>>>> This is mostly a GC change but I am sending it to the broader list
>>>>>>> since I added
>>>>>>> a method to ostream.hpp/cpp. We had this code duplicated in many
>>>>>>> places in the
>>>>>>> GC code:
>>>>>>>
>>>>>>> gclog_or_tty->date_stamp(PrintGCDateStamps);
>>>>>>> gclog_or_tty->stamp(PrintGCTimeStamps);
>>>>>>>
>>>>>>> And with my patch I had to add one more section to this code
>>>>>>> duplication.
>>>>>>> Instead I wrapped all three calls in a method called gclog_stamp().
>>>>>>> It is a bit
>>>>>>> hard to know where to place that method. ostream seems like the
>>>>>>> wrong place for
>>>>>>> GC specific code, but there is already lots of GC specific code
>>>>>>> there and even
>>>>>>> gclog_or_tty is declared there. So I added the method there for now:
>>>>>>>
>>>>>>> void outputStream::gclog_stamp(uint gc_id) {
>>>>>>>
>>>>>>> date_stamp(PrintGCDateStamps);
>>>>>>> stamp(PrintGCTimeStamps);
>>>>>>> if (PrintGCID) {
>>>>>>>
>>>>>>> print("#%u: ", gc_id);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> Other than that this is a pure GC change.
>>>>>>>
>>>>>>>
>>>>>>> Background:
>>>>>>>
>>>>>>> With event based tracing we introduced a GC id field on all GC
>>>>>>> events. This id
>>>>>>> is a constantly increasing number associated with each GC. I figured
>>>>>>> we can use
>>>>>>> the this GC id as a decoration for the HotSpot GC logging similarly
>>>>>>> to what we
>>>>>>> do with PrintGCTimeStamps and PrintGCDateStamps.
>>>>>>>
>>>>>>> A nice side effect of this is that it will make it easy to map an
>>>>>>> event in the
>>>>>>> event tracing to an entry in the GC log. Currently this is
>>>>>>> impossible to do
>>>>>>> deterministically since the logging and event tracing use different
>>>>>>> timing.
>>>>>>>
>>>>>>> I propose to add a flag called PrintGCID. Here's an example log
>>>>>>> entry for GC
>>>>>>> number 4 running with -XX:+PrintGCID:
>>>>>>>
>>>>>>> #4: [GC pause (G1 Evacuation Pause) (young) 185M->212M(502M),
>>>>>>> 0,2373420 secs]
>>>>>>>
>>>>>>> It is a decoration similar to the timestamps. Here's what it looks
>>>>>>> like if you
>>>>>>> add -XX:+PrintGCTimeStamps:
>>>>>>>
>>>>>>> 3,921: #4: [GC pause (G1 Evacuation Pause) (young)
>>>>>>> 185M->212M(502M), 0,2373420
>>>>>>> secs]
>>>>>>>
>>>>>>> And here's what it will look like if you add -XX:+PrintGCDateStamps:
>>>>>>>
>>>>>>> 2014-05-09T13:03:59.384+0200: 3,921: #4: [GC pause (G1 Evacuation
>>>>>>> Pause)
>>>>>>> (young) 185M->212M(502M), 0,2373420 secs]
>>>>>>>
>>>>>>>
>>>>>>> Here's a little longer example running ParallelGC:
>>>>>>>
>>>>>>> #0: [GC (Allocation Failure) 129024K->2980K(493056K), 0,1050244
>>> secs]
>>>
>>>>>>> #1: [GC (Allocation Failure) 132004K->3731K(622080K), 0,0389474
>>> secs]
>>>
>>>>>>> #2: [GC (Allocation Failure) 261779K->27153K(622080K), 0,2057294
>>> secs]
>>>
>>>>>>> #3: [GC (Allocation Failure) 285201K->224350K(880128K), 0,2410144
>>>>>>> secs]
>>>>>>> #4: [Full GC (Ergonomics) 224350K->219198K(1154560K), 2,7104481
>>> secs]
>>>
>>>>>>> #5: [GC (Allocation Failure) 735294K->638073K(863744K), 0,7707819
>>>>>>> secs]
>>>>>>>
>>>>>>> Note that for the concurrent GCs this gives a good way of seeing the
>>>>>>> concurrent
>>>>>>> action. Here is a G1 example:
>>>>>>>
>>>>>>> #0: [GC pause (G1 Evacuation Pause) (young) 24M->2881K(502M),
>>>>>>> 0,0383157 secs]
>>>>>>> #1: [GC pause (G1 Evacuation Pause) (young) 48M->4745K(502M),
>>>>>>> 0,0412220 secs]
>>>>>>> #2: [GC pause (G1 Evacuation Pause) (young) 136M->9618K(502M),
>>>>>>> 0,0426144 secs]
>>>>>>> #3: [GC pause (G1 Evacuation Pause) (young) 248M->143M(502M),
>>>>>>> 0,1467633 secs]
>>>>>>> #4: [GC pause (G1 Evacuation Pause) (young) 210M->199M(502M),
>>>>>>> 0,1627465 secs]
>>>>>>> #5: [GC pause (G1 Evacuation Pause) (young) 213M->235M(502M),
>>>>>>> 0,2376728 secs]
>>>>>>> #6: [GC pause (G1 Evacuation Pause) (young) (initial-mark)
>>>>>>> 255M->269M(1004M),
>>>>>>> 0,2623779 secs]
>>>>>>> #7: [GC concurrent-root-region-scan-start]
>>>>>>> #7: [GC concurrent-root-region-scan-end, 0,0158488 secs]
>>>>>>> #7: [GC concurrent-mark-start]
>>>>>>> #8: [GC pause (G1 Evacuation Pause) (young) 315M->330M(2008M),
>>>>>>> 0,3007405 secs]
>>>>>>> #9: [GC pause (G1 Evacuation Pause) (young) 422M->418M(3212M),
>>>>>>> 0,4063937 secs]
>>>>>>> #10: [GC pause (G1 Evacuation Pause) (young) 564M->572M(4176M),
>>>>>>> 0,7500609 secs]
>>>>>>> #11: [GC pause (G1 Evacuation Pause) (young) 760M->756M(4946M),
>>>>>>> 1,5464884 secs]
>>>>>>> #7: [GC concurrent-mark-end, 3,9464599 secs]
>>>>>>> #7: [GC remark, 0,0240462 secs]
>>>>>>> #7: [GC cleanup 801M->800M(4946M), 0,0108146 secs]
>>>>>>> #7: [GC concurrent-cleanup-start]
>>>>>>> #7: [GC concurrent-cleanup-end, 0,0000228 secs]
>>>>>>> #12: [GC pause (G1 Evacuation Pause) (young) 977M->978M(5562M),
>>>>>>> 2,2464423 secs]
>>>>>>>
>>>>>>> Notice how the complete concurrent cycle is decorated with id #7.
>>>>>>> That makes it
>>>>>>> possible to follow the concurrent work more easily and grep it out
>>> etc.
>>>
>>>>>>> Here's a similar thing for CMS where the concurrent cycle #22 has a
>>>>>>> young GC #23
>>>>>>> in the middle of it:
>>>>>>>
>>>>>>> #21: [GC (Allocation Failure) 1621551K->1107977K(2395632K),
>>>>>>> 1,4558792 secs]
>>>>>>> #22: [GC (CMS Initial Mark) 1336515K(2452584K), 0,1107938 secs]
>>>>>>> #23: [GC (Allocation Failure) 1768969K->1184500K(2452584K),
>>>>>>> 0,7909961 secs]
>>>>>>> #22: [GC (CMS Final Remark) 1304871K(2452584K), 0,2353840 secs]
>>>>>>>
>>>>>>>
>>>>>>> I think this is very helpful information to have, so I would like to
>>>>>>> push this
>>>>>>> with the new flag PrintGCID as true by default. I'm sure some
>>>>>>> parsers will
>>>>>>> break, but it is an easy work around to run with -XX:-PrintGCID to
>>>>>>> get the old
>>>>>>> format. It should even be pretty easy to do post processing on a log
>>>>>>> file to
>>>>>>> remove the GC id information. Having it on by default makes it
>>>>>>> possible for us
>>>>>>> to use this information and in particular be able to map it to the
>>>>>>> JFR events we
>>>>>>> see in MissionControl.
>>>>>>>
>>>>>>> I would also like to backport this to 8u40, but in that case with
>>>>>>> the default
>>>>>>> value of PrintGCID as false.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bengt
From staffan.larsen at oracle.com Thu Jun 5 11:52:37 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 5 Jun 2014 13:52:37 +0200
Subject: RFR: 8044797 Building with clang gives: fatal error: file '...'
has been modified since the precompiled header was built
In-Reply-To: <539056B3.50500@oracle.com>
References: <FCC688CB-C65B-4014-8D9E-610A68A4A981@oracle.com>
<539056B3.50500@oracle.com>
Message-ID: <A3549C62-06E5-4E6E-A7F4-15F5319D8EC4@oracle.com>
On 5 jun 2014, at 13:38, David Holmes <david.holmes at oracle.com> wrote:
> On 4/06/2014 11:54 PM, Staffan Larsen wrote:
>> When building with clang and changing a file that is part of the precompiled header, you can get:
>>
>> fatal error: file '/Users/staffan/mercurial/jdk9-hs-rt/hotspot/src/share/vm/runtime/thread.hpp' has been modified since the precompiled header was built
>>
>> clang behaves differently than gcc here.
>
> You mean clang reports an error when regenerating the pch file? That seems like a bug to me.
Yes. It also deletes the files, so rerunning the same command again succeeds...
>
> Deleting the file first seems quite reasonable.
Thanks.
/Staffan
>
> Thanks,
> David
>
>> Example with clang:
>>
>> $ ls
>> test.h
>> $ cat test.h
>> #include <stdio.h>
>> $ clang -x c-header -include test.h test.h -o test.h.pch
>> $ touch test.h
>> $ clang -x c-header -include test.h test.h -o test.h.pch
>> fatal error: file '/Users/staffan/tmp/pch/test.h' has been modified since the precompiled header was built
>> 1 error generated.
>>
>> Same with gcc:
>>
>> $ ls
>> test.h
>> $ cat test.h
>> #include <stdio.h>
>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>> $ touch test.h
>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>>
>>
>> The proposed fix is to delete the .pch file before calling clang or gcc.
>>
>> diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
>> --- a/make/bsd/makefiles/vm.make
>> +++ b/make/bsd/makefiles/vm.make
>> @@ -295,6 +295,7 @@
>> $(PRECOMPILED_HEADER):
>> $(QUIETLY) echo Generating precompiled header $@
>> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
>> + $(QUIETLY) rm -f $@
>> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>>
>> # making the library:
>>
>>
>> Thanks,
>> /Staffan
>>
From staffan.larsen at oracle.com Thu Jun 5 12:05:27 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 5 Jun 2014 14:05:27 +0200
Subject: RFR: 8044797 Building with clang gives: fatal error: file '...'
has been modified since the precompiled header was built
In-Reply-To: <A3549C62-06E5-4E6E-A7F4-15F5319D8EC4@oracle.com>
References: <FCC688CB-C65B-4014-8D9E-610A68A4A981@oracle.com>
<539056B3.50500@oracle.com>
<A3549C62-06E5-4E6E-A7F4-15F5319D8EC4@oracle.com>
Message-ID: <D7606C7F-FE43-4E55-9255-533D7F8DA6AF@oracle.com>
The same problem exists on linux, so here is a diff for both bsd and linux:
$ hg qdiff
diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
--- a/make/bsd/makefiles/vm.make
+++ b/make/bsd/makefiles/vm.make
@@ -295,6 +295,7 @@
$(PRECOMPILED_HEADER):
$(QUIETLY) echo Generating precompiled header $@
$(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
+ $(QUIETLY) rm -f $@
$(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
# making the library:
diff --git a/make/linux/makefiles/vm.make b/make/linux/makefiles/vm.make
--- a/make/linux/makefiles/vm.make
+++ b/make/linux/makefiles/vm.make
@@ -290,6 +290,7 @@
$(PRECOMPILED_HEADER):
$(QUIETLY) echo Generating precompiled header $@
$(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
+ $(QUIETLY) rm -f $@
$(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
# making the library:
On 5 jun 2014, at 13:52, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
> On 5 jun 2014, at 13:38, David Holmes <david.holmes at oracle.com> wrote:
>
>> On 4/06/2014 11:54 PM, Staffan Larsen wrote:
>>> When building with clang and changing a file that is part of the precompiled header, you can get:
>>>
>>> fatal error: file '/Users/staffan/mercurial/jdk9-hs-rt/hotspot/src/share/vm/runtime/thread.hpp' has been modified since the precompiled header was built
>>>
>>> clang behaves differently than gcc here.
>>
>> You mean clang reports an error when regenerating the pch file? That seems like a bug to me.
>
> Yes. It also deletes the files, so rerunning the same command again succeeds...
>
>>
>> Deleting the file first seems quite reasonable.
>
> Thanks.
>
> /Staffan
>
>>
>> Thanks,
>> David
>>
>>> Example with clang:
>>>
>>> $ ls
>>> test.h
>>> $ cat test.h
>>> #include <stdio.h>
>>> $ clang -x c-header -include test.h test.h -o test.h.pch
>>> $ touch test.h
>>> $ clang -x c-header -include test.h test.h -o test.h.pch
>>> fatal error: file '/Users/staffan/tmp/pch/test.h' has been modified since the precompiled header was built
>>> 1 error generated.
>>>
>>> Same with gcc:
>>>
>>> $ ls
>>> test.h
>>> $ cat test.h
>>> #include <stdio.h>
>>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>>> $ touch test.h
>>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>>>
>>>
>>> The proposed fix is to delete the .pch file before calling clang or gcc.
>>>
>>> diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
>>> --- a/make/bsd/makefiles/vm.make
>>> +++ b/make/bsd/makefiles/vm.make
>>> @@ -295,6 +295,7 @@
>>> $(PRECOMPILED_HEADER):
>>> $(QUIETLY) echo Generating precompiled header $@
>>> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
>>> + $(QUIETLY) rm -f $@
>>> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>>>
>>> # making the library:
>>>
>>>
>>> Thanks,
>>> /Staffan
>>>
>
From daniel.daugherty at oracle.com Thu Jun 5 12:50:06 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 05 Jun 2014 06:50:06 -0600
Subject: RFR: 8044797 Building with clang gives: fatal error: file '...'
has been modified since the precompiled header was built
In-Reply-To: <D7606C7F-FE43-4E55-9255-533D7F8DA6AF@oracle.com>
References: <FCC688CB-C65B-4014-8D9E-610A68A4A981@oracle.com>
<539056B3.50500@oracle.com>
<A3549C62-06E5-4E6E-A7F4-15F5319D8EC4@oracle.com>
<D7606C7F-FE43-4E55-9255-533D7F8DA6AF@oracle.com>
Message-ID: <5390677E.4080702@oracle.com>
On 6/5/14 6:05 AM, Staffan Larsen wrote:
> The same problem exists on linux, so here is a diff for both bsd and linux:
>
> $ hg qdiff
> diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
> --- a/make/bsd/makefiles/vm.make
> +++ b/make/bsd/makefiles/vm.make
> @@ -295,6 +295,7 @@
> $(PRECOMPILED_HEADER):
> $(QUIETLY) echo Generating precompiled header $@
> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
> + $(QUIETLY) rm -f $@
> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>
> # making the library:
> diff --git a/make/linux/makefiles/vm.make b/make/linux/makefiles/vm.make
> --- a/make/linux/makefiles/vm.make
> +++ b/make/linux/makefiles/vm.make
> @@ -290,6 +290,7 @@
> $(PRECOMPILED_HEADER):
> $(QUIETLY) echo Generating precompiled header $@
> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
> + $(QUIETLY) rm -f $@
> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>
> # making the library:
Looks fine. Should use the "$(RM) $@" form, but I see that the
current HotSpot makefiles are inconsistent about that. Sigh...
Dan
>
>
>
>
> On 5 jun 2014, at 13:52, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
>> On 5 jun 2014, at 13:38, David Holmes <david.holmes at oracle.com> wrote:
>>
>>> On 4/06/2014 11:54 PM, Staffan Larsen wrote:
>>>> When building with clang and changing a file that is part of the precompiled header, you can get:
>>>>
>>>> fatal error: file '/Users/staffan/mercurial/jdk9-hs-rt/hotspot/src/share/vm/runtime/thread.hpp' has been modified since the precompiled header was built
>>>>
>>>> clang behaves differently than gcc here.
>>> You mean clang reports an error when regenerating the pch file? That seems like a bug to me.
>> Yes. It also deletes the files, so rerunning the same command again succeeds...
>>
>>> Deleting the file first seems quite reasonable.
>> Thanks.
>>
>> /Staffan
>>
>>> Thanks,
>>> David
>>>
>>>> Example with clang:
>>>>
>>>> $ ls
>>>> test.h
>>>> $ cat test.h
>>>> #include <stdio.h>
>>>> $ clang -x c-header -include test.h test.h -o test.h.pch
>>>> $ touch test.h
>>>> $ clang -x c-header -include test.h test.h -o test.h.pch
>>>> fatal error: file '/Users/staffan/tmp/pch/test.h' has been modified since the precompiled header was built
>>>> 1 error generated.
>>>>
>>>> Same with gcc:
>>>>
>>>> $ ls
>>>> test.h
>>>> $ cat test.h
>>>> #include <stdio.h>
>>>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>>>> $ touch test.h
>>>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>>>>
>>>>
>>>> The proposed fix is to delete the .pch file before calling clang or gcc.
>>>>
>>>> diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
>>>> --- a/make/bsd/makefiles/vm.make
>>>> +++ b/make/bsd/makefiles/vm.make
>>>> @@ -295,6 +295,7 @@
>>>> $(PRECOMPILED_HEADER):
>>>> $(QUIETLY) echo Generating precompiled header $@
>>>> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
>>>> + $(QUIETLY) rm -f $@
>>>> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>>>>
>>>> # making the library:
>>>>
>>>>
>>>> Thanks,
>>>> /Staffan
>>>>
From thomas.schatzl at oracle.com Thu Jun 5 14:28:57 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 05 Jun 2014 16:28:57 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <538F35DE.1040802@oracle.com>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com>
<537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop>
<538F35DE.1040802@oracle.com>
Message-ID: <1401978537.2592.5.camel@cirrus>
Hi Bengt,
On Wed, 2014-06-04 at 17:06 +0200, Bengt Rutisson wrote:
> Hi Erik,
>
> On 5/28/14 2:29 PM, Erik Helin wrote:
> > Hi Bengt,
> >
> > just a first quick general comment: would it make sense for GCId to be
> > in its own file or class, so the GC logging don't have to depend on
> > the GC trace framework?
>
> Good point.
>
> Here is an updated webrev where I separeted out GCId to its own file:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
>
> Here's just the diff compared to the earlier version:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
>
> Jesper, the updated webrev also contains the spelling mistake you
> noticed. Thanks for catching that!
>
two minor comments:
- is it useful to check whether we are at a safepoint and running in the
VM thread when incrementing the gc id?
- also it would be nice to have some test case that checks for presence
of the numbers in log messages (and their absence if disabled).
Thanks,
Thomas
From christian.tornqvist at oracle.com Thu Jun 5 16:23:15 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 5 Jun 2014 12:23:15 -0400
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
Message-ID: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
Hi everyone,
This is a fix for building JDK9 with Visual Studio 2013, the fix is to add
_build_pch_file.obj to LD_FLAGS in vm.make when building with VS2012/2013.
Also added VS2013 to vm_version.cpp so that -Xinternalversion looks correct.
Cleaned up support for older versions of Visual Studio (2008 and older).
Mainstream support for these versions have ended:
http://support.microsoft.com/lifecycle/search/?sort=PN
<http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio>
&alpha=Visual+Studio and comments in the Hotspot code suggest we need VS2010
and later anyway.
Also cleaned up one of the warnings when building the SA with a CL option
that was removed in VS2005 (described by
https://bugs.openjdk.java.net/browse/JDK-6989106).
Changes have been tested in JPRT and locally on my Windows 8.1 x64 machine
using VS2010 and VS2013, built using gnu make:
Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
built on Jun 5 2014 08:19:39 by "Christian" with MS VC++ 10.0 (VS2010)
Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
built on Jun 5 2014 08:36:15 by "Christian" with MS VC++ 12.0 (VS2013)
Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
(1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++ 10.0
(VS2010)
Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
(1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++ 12.0
(VS2013)
and Visual Studio project (using create.bat):
Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
built on Jun 5 2014 09:11:10 by "Christian" with MS VC++ 10.0 (VS2010)
Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
built on Jun 5 2014 09:15:57 by "Christian" with MS VC++ 12.0 (VS2013)
Webrev can be found at:
http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8043492
Thanks,
Christian
From christian.thalinger at oracle.com Thu Jun 5 16:53:52 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 5 Jun 2014 09:53:52 -0700
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
Message-ID: <2DB3B97C-D1BC-4E53-9F2E-FC68CF8C075F@oracle.com>
make/windows/makefiles/compile.make
# 1600 is for VS2010
# 1700 is for VS2012
+# 1800 is for VS2012
Typo.
Otherwise this looks good.
On Jun 5, 2014, at 9:23 AM, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:
> Hi everyone,
>
>
>
> This is a fix for building JDK9 with Visual Studio 2013, the fix is to add
> _build_pch_file.obj to LD_FLAGS in vm.make when building with VS2012/2013.
> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks correct.
>
>
>
> Cleaned up support for older versions of Visual Studio (2008 and older).
> Mainstream support for these versions have ended:
>
> http://support.microsoft.com/lifecycle/search/?sort=PN
> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio>
> &alpha=Visual+Studio and comments in the Hotspot code suggest we need VS2010
> and later anyway.
>
>
>
> Also cleaned up one of the warnings when building the SA with a CL option
> that was removed in VS2005 (described by
> https://bugs.openjdk.java.net/browse/JDK-6989106).
>
>
>
> Changes have been tested in JPRT and locally on my Windows 8.1 x64 machine
> using VS2010 and VS2013, built using gnu make:
>
>
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:19:39 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:36:15 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++ 10.0
> (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++ 12.0
> (VS2013)
>
>
>
> and Visual Studio project (using create.bat):
>
>
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:11:10 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:15:57 by "Christian" with MS VC++ 12.0 (VS2013)
>
>
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8043492
>
>
>
> Thanks,
>
> Christian
>
From christian.tornqvist at oracle.com Thu Jun 5 16:57:44 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 5 Jun 2014 12:57:44 -0400
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <2DB3B97C-D1BC-4E53-9F2E-FC68CF8C075F@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
<2DB3B97C-D1BC-4E53-9F2E-FC68CF8C075F@oracle.com>
Message-ID: <097b01cf80df$45ef5990$d1ce0cb0$@oracle.com>
Fixed! Thanks for spotting this :)
From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Thursday, June 5, 2014 12:54 PM
To: Christian Tornqvist
Cc: hotspot-dev at openjdk.java.net; Tim Bell
Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
precompiled object not linked in; image may not run
make/windows/makefiles/compile.make
# 1600 is for VS2010
# 1700 is for VS2012
+# 1800 is for VS2012
Typo.
Otherwise this looks good.
On Jun 5, 2014, at 9:23 AM, Christian Tornqvist
<christian.tornqvist at oracle.com <mailto:christian.tornqvist at oracle.com> >
wrote:
Hi everyone,
This is a fix for building JDK9 with Visual Studio 2013, the fix is to add
_build_pch_file.obj to LD_FLAGS in vm.make when building with VS2012/2013.
Also added VS2013 to vm_version.cpp so that -Xinternalversion looks correct.
Cleaned up support for older versions of Visual Studio (2008 and older).
Mainstream support for these versions have ended:
http://support.microsoft.com/lifecycle/search/?sort=PN
<http://support.microsoft.com/lifecycle/search/?sort=PN
<http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio>
&alpha=Visual+Studio>
&alpha=Visual+Studio and comments in the Hotspot code suggest we need VS2010
and later anyway.
Also cleaned up one of the warnings when building the SA with a CL option
that was removed in VS2005 (described by
https://bugs.openjdk.java.net/browse/JDK-6989106).
Changes have been tested in JPRT and locally on my Windows 8.1 x64 machine
using VS2010 and VS2013, built using gnu make:
Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
built on Jun 5 2014 08:19:39 by "Christian" with MS VC++ 10.0 (VS2010)
Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
built on Jun 5 2014 08:36:15 by "Christian" with MS VC++ 12.0 (VS2013)
Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
(1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++ 10.0
(VS2010)
Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
(1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++ 12.0
(VS2013)
and Visual Studio project (using create.bat):
Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
built on Jun 5 2014 09:11:10 by "Christian" with MS VC++ 10.0 (VS2010)
Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
built on Jun 5 2014 09:15:57 by "Christian" with MS VC++ 12.0 (VS2013)
Webrev can be found at:
http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8043492
Thanks,
Christian
From lois.foltan at oracle.com Thu Jun 5 17:04:14 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 05 Jun 2014 13:04:14 -0400
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
Message-ID: <5390A30E.4060804@oracle.com>
Looks good, I was able to build with VS2013 and these changes, thanks!
Copyrights need to be updated.
Lois
On 6/5/2014 12:23 PM, Christian Tornqvist wrote:
> Hi everyone,
>
>
>
> This is a fix for building JDK9 with Visual Studio 2013, the fix is to add
> _build_pch_file.obj to LD_FLAGS in vm.make when building with VS2012/2013.
> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks correct.
>
>
>
> Cleaned up support for older versions of Visual Studio (2008 and older).
> Mainstream support for these versions have ended:
>
> http://support.microsoft.com/lifecycle/search/?sort=PN
> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio>
> &alpha=Visual+Studio and comments in the Hotspot code suggest we need VS2010
> and later anyway.
>
>
>
> Also cleaned up one of the warnings when building the SA with a CL option
> that was removed in VS2005 (described by
> https://bugs.openjdk.java.net/browse/JDK-6989106).
>
>
>
> Changes have been tested in JPRT and locally on my Windows 8.1 x64 machine
> using VS2010 and VS2013, built using gnu make:
>
>
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:19:39 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:36:15 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++ 10.0
> (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++ 12.0
> (VS2013)
>
>
>
> and Visual Studio project (using create.bat):
>
>
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:11:10 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:15:57 by "Christian" with MS VC++ 12.0 (VS2013)
>
>
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8043492
>
>
>
> Thanks,
>
> Christian
>
From staffan.larsen at oracle.com Thu Jun 5 18:02:16 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 5 Jun 2014 20:02:16 +0200
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <097b01cf80df$45ef5990$d1ce0cb0$@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
<2DB3B97C-D1BC-4E53-9F2E-FC68CF8C075F@oracle.com>
<097b01cf80df$45ef5990$d1ce0cb0$@oracle.com>
Message-ID: <D39BAAD3-CBC5-46B3-B7FB-31AE1CED370E@oracle.com>
Looks good!
Thanks,
/Staffan
On 5 jun 2014, at 18:57, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:
> Fixed! Thanks for spotting this :)
>
>
>
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
> Sent: Thursday, June 5, 2014 12:54 PM
> To: Christian Tornqvist
> Cc: hotspot-dev at openjdk.java.net; Tim Bell
> Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
> precompiled object not linked in; image may not run
>
>
>
>
> make/windows/makefiles/compile.make
>
> # 1600 is for VS2010
> # 1700 is for VS2012
> +# 1800 is for VS2012
>
> Typo.
>
>
>
> Otherwise this looks good.
>
>
>
> On Jun 5, 2014, at 9:23 AM, Christian Tornqvist
> <christian.tornqvist at oracle.com <mailto:christian.tornqvist at oracle.com> >
> wrote:
>
>
>
>
>
> Hi everyone,
>
>
>
> This is a fix for building JDK9 with Visual Studio 2013, the fix is to add
> _build_pch_file.obj to LD_FLAGS in vm.make when building with VS2012/2013.
> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks correct.
>
>
>
> Cleaned up support for older versions of Visual Studio (2008 and older).
> Mainstream support for these versions have ended:
>
> http://support.microsoft.com/lifecycle/search/?sort=PN
> <http://support.microsoft.com/lifecycle/search/?sort=PN
> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio>
> &alpha=Visual+Studio>
> &alpha=Visual+Studio and comments in the Hotspot code suggest we need VS2010
> and later anyway.
>
>
>
> Also cleaned up one of the warnings when building the SA with a CL option
> that was removed in VS2005 (described by
> https://bugs.openjdk.java.net/browse/JDK-6989106).
>
>
>
> Changes have been tested in JPRT and locally on my Windows 8.1 x64 machine
> using VS2010 and VS2013, built using gnu make:
>
>
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:19:39 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:36:15 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++ 10.0
> (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++ 12.0
> (VS2013)
>
>
>
> and Visual Studio project (using create.bat):
>
>
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:11:10 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:15:57 by "Christian" with MS VC++ 12.0 (VS2013)
>
>
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8043492
>
>
>
> Thanks,
>
> Christian
From vladimir.kozlov at oracle.com Thu Jun 5 18:36:49 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 05 Jun 2014 11:36:49 -0700
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
Message-ID: <5390B8C1.9090703@oracle.com>
On 6/5/14 9:23 AM, Christian Tornqvist wrote:
> Hi everyone,
>
> This is a fix for building JDK9 with Visual Studio 2013, the fix is to add
> _build_pch_file.obj to LD_FLAGS in vm.make when building with VS2012/2013.
> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks correct.
>
Your clean up is correct. We care only about jdk8u and jdk9 now. And we
use VS2010 (1600) for 9 and 8u.
We should not allow to build with old compilers since you removed all
code for them. But based on sanity.make we still allow it with
FORCE_MSC_VER.
Thanks,
Vladimir
>
>
> Cleaned up support for older versions of Visual Studio (2008 and older).
> Mainstream support for these versions have ended:
>
> http://support.microsoft.com/lifecycle/search/?sort=PN
> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio>
> &alpha=Visual+Studio and comments in the Hotspot code suggest we need VS2010
> and later anyway.
>
> Also cleaned up one of the warnings when building the SA with a CL option
> that was removed in VS2005 (described by
> https://bugs.openjdk.java.net/browse/JDK-6989106).
>
>
>
> Changes have been tested in JPRT and locally on my Windows 8.1 x64 machine
> using VS2010 and VS2013, built using gnu make:
>
>
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:19:39 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE (1.9.0),
> built on Jun 5 2014 08:36:15 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++ 10.0
> (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++ 12.0
> (VS2013)
>
>
>
> and Visual Studio project (using create.bat):
>
>
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built on Jun
> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:11:10 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE (1.9.0),
> built on Jun 5 2014 09:15:57 by "Christian" with MS VC++ 12.0 (VS2013)
>
>
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8043492
>
>
>
> Thanks,
>
> Christian
>
From christian.tornqvist at oracle.com Thu Jun 5 19:53:11 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 5 Jun 2014 15:53:11 -0400
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <5390B8C1.9090703@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
<5390B8C1.9090703@oracle.com>
Message-ID: <09fd01cf80f7$c86678f0$59336ad0$@oracle.com>
Hi Vladimir,
I think the option of overriding should be left in to make it easier to test
new/beta versions of Visual Studio. I could change the messages to something
like:
"*** WARNING *** Incorrect cl.exe version detected: $(MSC_VER), only
1600/1700/1800 (Visual Studio 2010/2012/2013) are supported"
"*** WARNING *** Incorrect link.exe version detected: $(LD_VER), only
1000/1100/1200 (Visual Studio 2010/2012/2013) are supported"
Would that make sense?
Thanks,
Christian
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Thursday, June 5, 2014 2:37 PM
To: hotspot-dev at openjdk.java.net
Cc: Christian T?rnqvist
Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
precompiled object not linked in; image may not run
On 6/5/14 9:23 AM, Christian Tornqvist wrote:
> Hi everyone,
>
> This is a fix for building JDK9 with Visual Studio 2013, the fix is to
> add _build_pch_file.obj to LD_FLAGS in vm.make when building with
VS2012/2013.
> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks
correct.
>
Your clean up is correct. We care only about jdk8u and jdk9 now. And we use
VS2010 (1600) for 9 and 8u.
We should not allow to build with old compilers since you removed all code
for them. But based on sanity.make we still allow it with FORCE_MSC_VER.
Thanks,
Vladimir
>
>
> Cleaned up support for older versions of Visual Studio (2008 and older).
> Mainstream support for these versions have ended:
>
> http://support.microsoft.com/lifecycle/search/?sort=PN
> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+S
> tudio> &alpha=Visual+Studio and comments in the Hotspot code suggest
> we need VS2010 and later anyway.
>
> Also cleaned up one of the warnings when building the SA with a CL
> option that was removed in VS2005 (described by
> https://bugs.openjdk.java.net/browse/JDK-6989106).
>
>
>
> Changes have been tested in JPRT and locally on my Windows 8.1 x64
> machine using VS2010 and VS2013, built using gnu make:
>
>
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
> (1.9.0), built on Jun 5 2014 08:19:39 by "Christian" with MS VC++
> 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
> (1.9.0), built on Jun 5 2014 08:36:15 by "Christian" with MS VC++
> 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
> JRE (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++
> 10.0
> (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
> JRE (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++
> 12.0
> (VS2013)
>
>
>
> and Visual Studio project (using create.bat):
>
>
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
> on Jun
> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>
> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
> on Jun
> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 09:11:10 by "Christian" with MS VC++
> 10.0 (VS2010)
>
> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
> (1.9.0), built on Jun 5 2014 09:15:57 by "Christian" with MS VC++
> 12.0 (VS2013)
>
>
>
> Webrev can be found at:
>
> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>
>
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8043492
>
>
>
> Thanks,
>
> Christian
>
From goetz.lindenmaier at sap.com Thu Jun 5 20:23:59 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 5 Jun 2014 20:23:59 +0000
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <53902C7E.5010108@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
<53902C7E.5010108@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC706B@DEWDFEMB12A.global.corp.sap>
Hi Stefan,
thanks for the thorough review!
> Thanks again for cleaning up the include files.
I checked the other includes, I would like to do this for os_<os>.inline.hpp, too.
That include cascade is shorter, but used in around 30 files.
Other more prominent cascades are
bytes_<cpu>.hpp (12 cascades),
ad_<cpu>.hpp (10 cascades),
nativeInst_<cpu>.hpp (8)
vmreg.inline_<cpu>.hpp (7)
As we have another 3 cpus (zArch, parisc, ia64), that would clean up our code
nicely ;)
Back to this change:
I moved the Atomics in StringDedup.hpp as you requested.
I removed the include in markSweep.inline.hpp.
I moved the include in oop.pcgc.inline.hpp up.
I moved the debug methods in gcLocker.hpp to the cpp file.
> This is a lot of noise just to get rid of a call to the the
> CompiledICHolder constructor in product builds. Is it really worth it?
I think not. Moved to cpp file.
About adding the header to precompiled.hpp: I don't really care,
I just follow the current pattern. As there were no other comments
on your request in the last change, I removed it this time.
Here is the new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.01
Best regards,
Goetz.
-----Original Message-----
From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
Sent: Donnerstag, 5. Juni 2014 10:38
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
Hi Goetz,
Thanks again for cleaning up the include files.
On 2014-06-04 15:59, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to do another change cleaning up the includes of
> .inline.hpp files from the os_cpu directories.
>
> Please review and test this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.hpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.cpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupQueue.cpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp.udiff.html
I think it would be good to move the Atomic calls out from the
g1StringDedup.hpp to g1StringDedup.cpp. I talked to Per, the author of
StringDedup, and he would be fine with that move.
I moved the debug methods in gcLocker.hpp to the cpp file.
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.frames.html
32 #if INCLUDE_ALL_GCS
33 #include "gc_implementation/g1/g1StringDedup.hpp"
34 #include "gc_implementation/parallelScavenge/psParallelCompact.hpp"
35 #include "runtime/atomic.inline.hpp"
36 #endif // INCLUDE_ALL_GCS
Why was this include added? Was it becuase g1StringDedup.hpp was added?
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/mutableSpace.cpp.frames.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/oop.pcgc.inline.hpp.frames.html
25 #include "precompiled.hpp"
26 #include "utilities/macros.hpp"
27 #if INCLUDE_ALL_GCS
28 #include "gc_implementation/shared/mutableSpace.hpp"
29 #include "gc_implementation/shared/spaceDecorator.hpp"
30 #include "oops/oop.inline.hpp"
31 #include "runtime/safepoint.hpp"
32 #include "runtime/thread.hpp"
33 #endif // INCLUDE_ALL_GCS
34 #include "runtime/atomic.inline.hpp"
Could you place the new includes together with the includes before the
INCLUDE_ALL_GCS block?
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.hpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.inline.hpp.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/runtime/safepoint.cpp.udiff.html
+ inline static void increment_debug_jni_lock_count();
+ inline static void decrement_debug_jni_lock_count();
This is debugging code, so it would be better to move it to the .cpp file.
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/compiledICHolder.hpp.udiff.html
54 #ifdef ASSERT
55 CompiledICHolder(Method* method, Klass* klass);
56 #else
57 CompiledICHolder(Method* method, Klass* klass)
58 : _holder_method(method), _holder_klass(klass) {};
59 #endif
60
61 ~CompiledICHolder() NOT_DEBUG_RETURN;
This is a lot of noise just to get rid of a call to the the
CompiledICHolder constructor in product builds. Is it really worth it?
http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/precompiled/precompiled.hpp.udiff.html
# include "runtime/atomic.hpp"
+# include "runtime/atomic.inline.hpp"
I still think this is a bad idea. It will just make it more likely that
someone building with precompiled headers will forget to include
atomic.inline.hpp, and we would have to clean it up later when we found
out that it breaks some platform outside of Oracle's test matrix.
thanks,
StefanK
>
> This change improves the usage of the umbrella header atomic.inline.hpp.
> It removes includes of this header in files where it's not needed,
> and adds it in all .cpp and .inline.hpp files where a method of
> Atomic declared 'inline' is used.
>
> Also, the change moves some calls to such methods from .hpp files to
> .inline.hpp files. In case of ASSERT code it moves the calls
> to .cpp files.
>
> A row of headers still contain calls to inline methods of Atomic,
> which I don't want to move as no appropriate .inline.hpp file is existing:
>
> src/share/vm/compiler/compileBroker.hpp
> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
> src/share/vm/memory/specialized_oop_closures.hpp
> src/share/vm/oops/methodData.hpp
> src/share/vm/runtime/safepoint.hpp
> src/share/vm/services/lowMemoryDetector.hpp
> src/share/vm/services/memTracker.hpp
> src/share/vm/utilities/taskqueue.hpp
>
> I compiled and tested this without precompiled headers on
> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
> in opt, dbg and fastdbg versions.
>
> Best regards,
> Goetz.
From vladimir.kozlov at oracle.com Thu Jun 5 20:33:30 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 05 Jun 2014 13:33:30 -0700
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <09fd01cf80f7$c86678f0$59336ad0$@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
<5390B8C1.9090703@oracle.com>
<09fd01cf80f7$c86678f0$59336ad0$@oracle.com>
Message-ID: <5390D41A.2070308@oracle.com>
It is fine if specified version > 1800.
My concern is if user specify FORCE_MSC_VER=1400 to use VS2005 and his
build will break in some strange place, for example, in sa.make due to
your change. So should we stop the build gracefully if used VS is not
supported or let it fail late (or produce broken code which is worse)
with just warning message?
The warning message should be "1600 or later (Visual Studio 2010 or
later)" to avoid updating it again in a future.
Vladimir
On 6/5/14 12:53 PM, Christian Tornqvist wrote:
> Hi Vladimir,
>
> I think the option of overriding should be left in to make it easier to test
> new/beta versions of Visual Studio. I could change the messages to something
> like:
>
> "*** WARNING *** Incorrect cl.exe version detected: $(MSC_VER), only
> 1600/1700/1800 (Visual Studio 2010/2012/2013) are supported"
> "*** WARNING *** Incorrect link.exe version detected: $(LD_VER), only
> 1000/1100/1200 (Visual Studio 2010/2012/2013) are supported"
>
> Would that make sense?
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, June 5, 2014 2:37 PM
> To: hotspot-dev at openjdk.java.net
> Cc: Christian T?rnqvist
> Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
> precompiled object not linked in; image may not run
>
> On 6/5/14 9:23 AM, Christian Tornqvist wrote:
>> Hi everyone,
>>
>> This is a fix for building JDK9 with Visual Studio 2013, the fix is to
>> add _build_pch_file.obj to LD_FLAGS in vm.make when building with
> VS2012/2013.
>> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks
> correct.
>>
>
> Your clean up is correct. We care only about jdk8u and jdk9 now. And we use
> VS2010 (1600) for 9 and 8u.
>
> We should not allow to build with old compilers since you removed all code
> for them. But based on sanity.make we still allow it with FORCE_MSC_VER.
>
> Thanks,
> Vladimir
>
>>
>>
>> Cleaned up support for older versions of Visual Studio (2008 and older).
>> Mainstream support for these versions have ended:
>>
>> http://support.microsoft.com/lifecycle/search/?sort=PN
>> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+S
>> tudio> &alpha=Visual+Studio and comments in the Hotspot code suggest
>> we need VS2010 and later anyway.
>>
>> Also cleaned up one of the warnings when building the SA with a CL
>> option that was removed in VS2005 (described by
>> https://bugs.openjdk.java.net/browse/JDK-6989106).
>>
>>
>>
>> Changes have been tested in JPRT and locally on my Windows 8.1 x64
>> machine using VS2010 and VS2013, built using gnu make:
>>
>>
>>
>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
>> (1.9.0), built on Jun 5 2014 08:19:39 by "Christian" with MS VC++
>> 10.0 (VS2010)
>>
>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
>> (1.9.0), built on Jun 5 2014 08:36:15 by "Christian" with MS VC++
>> 12.0 (VS2013)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
>> JRE (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS VC++
>> 10.0
>> (VS2010)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
>> JRE (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS VC++
>> 12.0
>> (VS2013)
>>
>>
>>
>> and Visual Studio project (using create.bat):
>>
>>
>>
>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
>> on Jun
>> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>>
>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
>> on Jun
>> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
>> (1.9.0), built on Jun 5 2014 09:11:10 by "Christian" with MS VC++
>> 10.0 (VS2010)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
>> (1.9.0), built on Jun 5 2014 09:15:57 by "Christian" with MS VC++
>> 12.0 (VS2013)
>>
>>
>>
>> Webrev can be found at:
>>
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>>
>>
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8043492
>>
>>
>>
>> Thanks,
>>
>> Christian
>>
>
From christian.tornqvist at oracle.com Thu Jun 5 20:43:17 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 5 Jun 2014 16:43:17 -0400
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <5390D41A.2070308@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
<5390B8C1.9090703@oracle.com>
<09fd01cf80f7$c86678f0$59336ad0$@oracle.com>
<5390D41A.2070308@oracle.com>
Message-ID: <0a2b01cf80fe$c82eea00$588cbe00$@oracle.com>
>My concern is if user specify FORCE_MSC_VER=1400 to use VS2005 and his
build will break in some strange place, for example, in sa.make due to your
change. So should we stop the build gracefully if used VS is not supported
or let it fail late (or produce broken code which is worse) with just
warning message?
I think the warning should be enough?
>The warning message should be "1600 or later (Visual Studio 2010 or later)"
to avoid updating it again in a future.
We only know that 2010/2012/2013 works (and we're explicitly checking for
it), if someone tries to compile with say Visual Studio 2020 we should say
that it's not supported since we don't know if it actually works. We need to
update the makefiles for new versions of Visual Studio anyway so I don't see
this as a major thing.
Thanks,
Christian
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Thursday, June 5, 2014 4:34 PM
To: Christian Tornqvist; hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
precompiled object not linked in; image may not run
It is fine if specified version > 1800.
My concern is if user specify FORCE_MSC_VER=1400 to use VS2005 and his build
will break in some strange place, for example, in sa.make due to your
change. So should we stop the build gracefully if used VS is not supported
or let it fail late (or produce broken code which is worse) with just
warning message?
The warning message should be "1600 or later (Visual Studio 2010 or later)"
to avoid updating it again in a future.
Vladimir
On 6/5/14 12:53 PM, Christian Tornqvist wrote:
> Hi Vladimir,
>
> I think the option of overriding should be left in to make it easier
> to test new/beta versions of Visual Studio. I could change the
> messages to something
> like:
>
> "*** WARNING *** Incorrect cl.exe version detected: $(MSC_VER), only
> 1600/1700/1800 (Visual Studio 2010/2012/2013) are supported"
> "*** WARNING *** Incorrect link.exe version detected: $(LD_VER), only
> 1000/1100/1200 (Visual Studio 2010/2012/2013) are supported"
>
> Would that make sense?
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, June 5, 2014 2:37 PM
> To: hotspot-dev at openjdk.java.net
> Cc: Christian T?rnqvist
> Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
> precompiled object not linked in; image may not run
>
> On 6/5/14 9:23 AM, Christian Tornqvist wrote:
>> Hi everyone,
>>
>> This is a fix for building JDK9 with Visual Studio 2013, the fix is
>> to add _build_pch_file.obj to LD_FLAGS in vm.make when building with
> VS2012/2013.
>> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks
> correct.
>>
>
> Your clean up is correct. We care only about jdk8u and jdk9 now. And
> we use
> VS2010 (1600) for 9 and 8u.
>
> We should not allow to build with old compilers since you removed all
> code for them. But based on sanity.make we still allow it with
FORCE_MSC_VER.
>
> Thanks,
> Vladimir
>
>>
>>
>> Cleaned up support for older versions of Visual Studio (2008 and older).
>> Mainstream support for these versions have ended:
>>
>> http://support.microsoft.com/lifecycle/search/?sort=PN
>> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+
>> S
>> tudio> &alpha=Visual+Studio and comments in the Hotspot code suggest
>> we need VS2010 and later anyway.
>>
>> Also cleaned up one of the warnings when building the SA with a CL
>> option that was removed in VS2005 (described by
>> https://bugs.openjdk.java.net/browse/JDK-6989106).
>>
>>
>>
>> Changes have been tested in JPRT and locally on my Windows 8.1 x64
>> machine using VS2010 and VS2013, built using gnu make:
>>
>>
>>
>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
>> (1.9.0), built on Jun 5 2014 08:19:39 by "Christian" with MS VC++
>> 10.0 (VS2010)
>>
>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
>> (1.9.0), built on Jun 5 2014 08:36:15 by "Christian" with MS VC++
>> 12.0 (VS2013)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
>> JRE (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS
>> VC++
>> 10.0
>> (VS2010)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
>> JRE (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS
>> VC++
>> 12.0
>> (VS2013)
>>
>>
>>
>> and Visual Studio project (using create.bat):
>>
>>
>>
>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
>> on Jun
>> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>>
>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
>> on Jun
>> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
>> (1.9.0), built on Jun 5 2014 09:11:10 by "Christian" with MS VC++
>> 10.0 (VS2010)
>>
>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
>> (1.9.0), built on Jun 5 2014 09:15:57 by "Christian" with MS VC++
>> 12.0 (VS2013)
>>
>>
>>
>> Webrev can be found at:
>>
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>>
>>
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8043492
>>
>>
>>
>> Thanks,
>>
>> Christian
>>
>
From vladimir.kozlov at oracle.com Thu Jun 5 20:48:43 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 05 Jun 2014 13:48:43 -0700
Subject: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011: precompiled
object not linked in; image may not run
In-Reply-To: <0a2b01cf80fe$c82eea00$588cbe00$@oracle.com>
References: <096201cf80da$749b89d0$5dd29d70$@oracle.com>
<5390B8C1.9090703@oracle.com>
<09fd01cf80f7$c86678f0$59336ad0$@oracle.com>
<5390D41A.2070308@oracle.com>
<0a2b01cf80fe$c82eea00$588cbe00$@oracle.com>
Message-ID: <5390D7AB.8060403@oracle.com>
On 6/5/14 1:43 PM, Christian Tornqvist wrote:
>> My concern is if user specify FORCE_MSC_VER=1400 to use VS2005 and his
> build will break in some strange place, for example, in sa.make due to your
> change. So should we stop the build gracefully if used VS is not supported
> or let it fail late (or produce broken code which is worse) with just
> warning message?
>
> I think the warning should be enough?
In some sense yes. He was warned, so he can't file a bug.
>
>> The warning message should be "1600 or later (Visual Studio 2010 or later)"
> to avoid updating it again in a future.
>
> We only know that 2010/2012/2013 works (and we're explicitly checking for
> it), if someone tries to compile with say Visual Studio 2020 we should say
> that it's not supported since we don't know if it actually works. We need to
> update the makefiles for new versions of Visual Studio anyway so I don't see
> this as a major thing.
Okay, I agree.
Reviewed.
Thanks,
Vladimir
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, June 5, 2014 4:34 PM
> To: Christian Tornqvist; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
> precompiled object not linked in; image may not run
>
> It is fine if specified version > 1800.
>
> My concern is if user specify FORCE_MSC_VER=1400 to use VS2005 and his build
> will break in some strange place, for example, in sa.make due to your
> change. So should we stop the build gracefully if used VS is not supported
> or let it fail late (or produce broken code which is worse) with just
> warning message?
>
> The warning message should be "1600 or later (Visual Studio 2010 or later)"
> to avoid updating it again in a future.
>
> Vladimir
>
> On 6/5/14 12:53 PM, Christian Tornqvist wrote:
>> Hi Vladimir,
>>
>> I think the option of overriding should be left in to make it easier
>> to test new/beta versions of Visual Studio. I could change the
>> messages to something
>> like:
>>
>> "*** WARNING *** Incorrect cl.exe version detected: $(MSC_VER), only
>> 1600/1700/1800 (Visual Studio 2010/2012/2013) are supported"
>> "*** WARNING *** Incorrect link.exe version detected: $(LD_VER), only
>> 1000/1100/1200 (Visual Studio 2010/2012/2013) are supported"
>>
>> Would that make sense?
>>
>> Thanks,
>> Christian
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Thursday, June 5, 2014 2:37 PM
>> To: hotspot-dev at openjdk.java.net
>> Cc: Christian T?rnqvist
>> Subject: Re: RFR(M): 8043492 - ad_x86_64_misc.obj : error LNK2011:
>> precompiled object not linked in; image may not run
>>
>> On 6/5/14 9:23 AM, Christian Tornqvist wrote:
>>> Hi everyone,
>>>
>>> This is a fix for building JDK9 with Visual Studio 2013, the fix is
>>> to add _build_pch_file.obj to LD_FLAGS in vm.make when building with
>> VS2012/2013.
>>> Also added VS2013 to vm_version.cpp so that -Xinternalversion looks
>> correct.
>>>
>>
>> Your clean up is correct. We care only about jdk8u and jdk9 now. And
>> we use
>> VS2010 (1600) for 9 and 8u.
>>
>> We should not allow to build with old compilers since you removed all
>> code for them. But based on sanity.make we still allow it with
> FORCE_MSC_VER.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>>
>>> Cleaned up support for older versions of Visual Studio (2008 and older).
>>> Mainstream support for these versions have ended:
>>>
>>> http://support.microsoft.com/lifecycle/search/?sort=PN
>>> <http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+
>>> S
>>> tudio> &alpha=Visual+Studio and comments in the Hotspot code suggest
>>> we need VS2010 and later anyway.
>>>
>>> Also cleaned up one of the warnings when building the SA with a CL
>>> option that was removed in VS2005 (described by
>>> https://bugs.openjdk.java.net/browse/JDK-6989106).
>>>
>>>
>>>
>>> Changes have been tested in JPRT and locally on my Windows 8.1 x64
>>> machine using VS2010 and VS2013, built using gnu make:
>>>
>>>
>>>
>>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
>>> (1.9.0), built on Jun 5 2014 08:19:39 by "Christian" with MS VC++
>>> 10.0 (VS2010)
>>>
>>> Java HotSpot(TM) Server VM (1.9.0-internal) for windows-x86 JRE
>>> (1.9.0), built on Jun 5 2014 08:36:15 by "Christian" with MS VC++
>>> 12.0 (VS2013)
>>>
>>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
>>> JRE (1.9.0), built on Jun 5 2014 08:31:36 by "Christian" with MS
>>> VC++
>>> 10.0
>>> (VS2010)
>>>
>>> Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal) for windows-amd64
>>> JRE (1.9.0), built on Jun 5 2014 08:26:51 by "Christian" with MS
>>> VC++
>>> 12.0
>>> (VS2013)
>>>
>>>
>>>
>>> and Visual Studio project (using create.bat):
>>>
>>>
>>>
>>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
>>> on Jun
>>> 5 2014 09:24:42 by "Christian" with MS VC++ 10.0 (VS2010)
>>>
>>> Java HotSpot(TM) Server VM (1.9.0) for windows-x86 JRE (1.9.0), built
>>> on Jun
>>> 5 2014 09:19:32 by "Christian" with MS VC++ 12.0 (VS2013)
>>>
>>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
>>> (1.9.0), built on Jun 5 2014 09:11:10 by "Christian" with MS VC++
>>> 10.0 (VS2010)
>>>
>>> Java HotSpot(TM) 64-Bit Server VM (1.9.0) for windows-amd64 JRE
>>> (1.9.0), built on Jun 5 2014 09:15:57 by "Christian" with MS VC++
>>> 12.0 (VS2013)
>>>
>>>
>>>
>>> Webrev can be found at:
>>>
>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8043492/webrev.00/
>>>
>>>
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8043492
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Christian
>>>
>>
>
From bengt.rutisson at oracle.com Thu Jun 5 20:58:33 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 05 Jun 2014 22:58:33 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <1401978537.2592.5.camel@cirrus>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com>
<537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop>
<538F35DE.1040802@oracle.com> <1401978537.2592.5.camel@cirrus>
Message-ID: <5390D9F9.2080202@oracle.com>
Hi Thomas,
Thanks for looking at this!
On 6/5/14 4:28 PM, Thomas Schatzl wrote:
> Hi Bengt,
>
> On Wed, 2014-06-04 at 17:06 +0200, Bengt Rutisson wrote:
>> Hi Erik,
>>
>> On 5/28/14 2:29 PM, Erik Helin wrote:
>>> Hi Bengt,
>>>
>>> just a first quick general comment: would it make sense for GCId to be
>>> in its own file or class, so the GC logging don't have to depend on
>>> the GC trace framework?
>> Good point.
>>
>> Here is an updated webrev where I separeted out GCId to its own file:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
>>
>> Here's just the diff compared to the earlier version:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
>>
>> Jesper, the updated webrev also contains the spelling mistake you
>> noticed. Thanks for catching that!
>>
> two minor comments:
>
> - is it useful to check whether we are at a safepoint and running in the
> VM thread when incrementing the gc id?
Good idea. Added an assert for that.
>
> - also it would be nice to have some test case that checks for presence
> of the numbers in log messages (and their absence if disabled).
Yes, good point. I added a simple test.
Here's an updated webrev:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.04/
And here is the diff compared to the previous version:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.03-04.diff/
Note that I also found a minor bug. The peek() method should not use
"+1" the _next_id is already the next id, just like the name suggests
;). This only affect CMS and I noticed the problem since some IDs could
sometimes be skipped. Now it works fine for CMS too.
I also had to fix includes to make it compile without precompiled headers.
Thanks,
Bengt
>
> Thanks,
> Thomas
>
>
From david.holmes at oracle.com Fri Jun 6 05:39:15 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 06 Jun 2014 15:39:15 +1000
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <538F453E.6010105@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
Message-ID: <53915403.4030005@oracle.com>
Hi Dmitry,
The existing nomenclature uses needs_xxx not requires_xxx, please
maintain consistency with what exists.
Thanks,
David
On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
> Hello,
>
> This fix introduces new jtreg groups to allow not running tests which
> could conflict because of GC.
> Please note, this solution is temporary for 2-3 months, unless jtreg
> starts support the @requires tag
> (CODETOOLS-7900307)
> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>
> The change itself doesn't affect anything, it just allows to run group
> of tests which doesn't require a specific gc.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
> Webrev: http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>
> Testing:
> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC and saw
> only known issues not related to the conflict of flags.
>
> Thanks,
> Dima
From david.holmes at oracle.com Fri Jun 6 05:42:59 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 06 Jun 2014 15:42:59 +1000
Subject: RFR: 8044797 Building with clang gives: fatal error: file '...'
has been modified since the precompiled header was built
In-Reply-To: <5390677E.4080702@oracle.com>
References: <FCC688CB-C65B-4014-8D9E-610A68A4A981@oracle.com>
<539056B3.50500@oracle.com>
<A3549C62-06E5-4E6E-A7F4-15F5319D8EC4@oracle.com>
<D7606C7F-FE43-4E55-9255-533D7F8DA6AF@oracle.com>
<5390677E.4080702@oracle.com>
Message-ID: <539154E3.8090601@oracle.com>
On 5/06/2014 10:50 PM, Daniel D. Daugherty wrote:
> On 6/5/14 6:05 AM, Staffan Larsen wrote:
>> The same problem exists on linux, so here is a diff for both bsd and
>> linux:
>>
>> $ hg qdiff
>> diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
>> --- a/make/bsd/makefiles/vm.make
>> +++ b/make/bsd/makefiles/vm.make
>> @@ -295,6 +295,7 @@
>> $(PRECOMPILED_HEADER):
>> $(QUIETLY) echo Generating precompiled header $@
>> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
>> + $(QUIETLY) rm -f $@
>> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header
>> $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>>
>> # making the library:
>> diff --git a/make/linux/makefiles/vm.make b/make/linux/makefiles/vm.make
>> --- a/make/linux/makefiles/vm.make
>> +++ b/make/linux/makefiles/vm.make
>> @@ -290,6 +290,7 @@
>> $(PRECOMPILED_HEADER):
>> $(QUIETLY) echo Generating precompiled header $@
>> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
>> + $(QUIETLY) rm -f $@
>> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header
>> $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>>
>> # making the library:
>
> Looks fine.
+1
> Should use the "$(RM) $@" form, but I see that the
> current HotSpot makefiles are inconsistent about that. Sigh...
Alas the same is true for mkdir, echo, ...
David
> Dan
>
>
>>
>>
>>
>>
>> On 5 jun 2014, at 13:52, Staffan Larsen <staffan.larsen at oracle.com>
>> wrote:
>>
>>> On 5 jun 2014, at 13:38, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>>> On 4/06/2014 11:54 PM, Staffan Larsen wrote:
>>>>> When building with clang and changing a file that is part of the
>>>>> precompiled header, you can get:
>>>>>
>>>>> fatal error: file
>>>>> '/Users/staffan/mercurial/jdk9-hs-rt/hotspot/src/share/vm/runtime/thread.hpp'
>>>>> has been modified since the precompiled header was built
>>>>>
>>>>> clang behaves differently than gcc here.
>>>> You mean clang reports an error when regenerating the pch file? That
>>>> seems like a bug to me.
>>> Yes. It also deletes the files, so rerunning the same command again
>>> succeeds...
>>>
>>>> Deleting the file first seems quite reasonable.
>>> Thanks.
>>>
>>> /Staffan
>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Example with clang:
>>>>>
>>>>> $ ls
>>>>> test.h
>>>>> $ cat test.h
>>>>> #include <stdio.h>
>>>>> $ clang -x c-header -include test.h test.h -o test.h.pch
>>>>> $ touch test.h
>>>>> $ clang -x c-header -include test.h test.h -o test.h.pch
>>>>> fatal error: file '/Users/staffan/tmp/pch/test.h' has been modified
>>>>> since the precompiled header was built
>>>>> 1 error generated.
>>>>>
>>>>> Same with gcc:
>>>>>
>>>>> $ ls
>>>>> test.h
>>>>> $ cat test.h
>>>>> #include <stdio.h>
>>>>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>>>>> $ touch test.h
>>>>> $ gcc -x c-header -include test.h test.h -o test.h.pch
>>>>>
>>>>>
>>>>> The proposed fix is to delete the .pch file before calling clang or
>>>>> gcc.
>>>>>
>>>>> diff --git a/make/bsd/makefiles/vm.make b/make/bsd/makefiles/vm.make
>>>>> --- a/make/bsd/makefiles/vm.make
>>>>> +++ b/make/bsd/makefiles/vm.make
>>>>> @@ -295,6 +295,7 @@
>>>>> $(PRECOMPILED_HEADER):
>>>>> $(QUIETLY) echo Generating precompiled header $@
>>>>> $(QUIETLY) mkdir -p $(PRECOMPILED_HEADER_DIR)
>>>>> + $(QUIETLY) rm -f $@
>>>>> $(QUIETLY) $(COMPILE.CXX) $(DEPFLAGS) -x c++-header
>>>>> $(PRECOMPILED_HEADER_SRC) -o $@ $(COMPILE_DONE)
>>>>>
>>>>> # making the library:
>>>>>
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>>>>
>
From david.holmes at oracle.com Fri Jun 6 05:47:14 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 06 Jun 2014 15:47:14 +1000
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <53915403.4030005@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com>
Message-ID: <539155E2.2050901@oracle.com>
On 6/06/2014 3:39 PM, David Holmes wrote:
> Hi Dmitry,
>
> The existing nomenclature uses needs_xxx not requires_xxx, please
> maintain consistency with what exists.
And yes I'm guilty of naming the groups needs_xxx while in the comments
I keep saying requires.
David
> Thanks,
> David
>
>
>
> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>> Hello,
>>
>> This fix introduces new jtreg groups to allow not running tests which
>> could conflict because of GC.
>> Please note, this solution is temporary for 2-3 months, unless jtreg
>> starts support the @requires tag
>> (CODETOOLS-7900307)
>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>
>> The change itself doesn't affect anything, it just allows to run group
>> of tests which doesn't require a specific gc.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>> Webrev:
>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>
>> Testing:
>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC and saw
>> only known issues not related to the conflict of flags.
>>
>> Thanks,
>> Dima
From nils.eliasson at oracle.com Mon Jun 9 08:53:59 2014
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 09 Jun 2014 10:53:59 +0200
Subject: [8u20] RFR(S)JDK-8034188 OSR methods may not be recompiled at proper
compilation level after deoptimization
Message-ID: <53957627.90907@oracle.com>
HI,
I would like to request a 8u20 backport of JDK-8034188.
The change where pushed to jdk 9 on 2014-03-11. Nightly testing has
shown no problems. The change applies to 8u20 without conflicts.
Master bug: https://bugs.openjdk.java.net/browse/JDK-8034188
Webrev: http://cr.openjdk.java.net/~neliasso/8034188_8u20/webrev.01/
Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/47f00f3b3900
Thanks,
Nils
From dmitry.fazunenko at oracle.com Mon Jun 9 09:55:25 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Mon, 09 Jun 2014 13:55:25 +0400
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <539155E2.2050901@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
Message-ID: <5395848D.2010704@oracle.com>
Hi David,
This is the updated version:
http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
I ran all applicable_* groups with the corresponding GC. No failures
caused by conflicts.
Thanks,
Dima
On 06.06.2014 9:47, David Holmes wrote:
> On 6/06/2014 3:39 PM, David Holmes wrote:
>> Hi Dmitry,
>>
>> The existing nomenclature uses needs_xxx not requires_xxx, please
>> maintain consistency with what exists.
>
> And yes I'm guilty of naming the groups needs_xxx while in the
> comments I keep saying requires.
>
> David
>
>> Thanks,
>> David
>>
>>
>>
>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>> Hello,
>>>
>>> This fix introduces new jtreg groups to allow not running tests which
>>> could conflict because of GC.
>>> Please note, this solution is temporary for 2-3 months, unless jtreg
>>> starts support the @requires tag
>>> (CODETOOLS-7900307)
>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>
>>> The change itself doesn't affect anything, it just allows to run group
>>> of tests which doesn't require a specific gc.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>> Webrev:
>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>
>>> Testing:
>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC and
>>> saw
>>> only known issues not related to the conflict of flags.
>>>
>>> Thanks,
>>> Dima
From bengt.rutisson at oracle.com Mon Jun 9 12:04:42 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 09 Jun 2014 14:04:42 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <5390D9F9.2080202@oracle.com>
References: <537C7264.70200@oracle.com>
<537DAA00.2010104@oracle.com> <537ED5FC.6080702@oracle.com>
<2198629.dbW8eWbo0l@ehelin-desktop> <538F35DE.1040802@oracle.com>
<1401978537.2592.5.camel@cirrus> <5390D9F9.2080202@oracle.com>
Message-ID: <5395A2DA.3000507@oracle.com>
Hi again,
Another updated webrev:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.05/
Mainly two changes compared to the previous version. I had to remove the
assert hat we only increment the GC id during a safepoint. That is not
true for CMS, but I remember us looking thoroughly at that when we
introduced the GC id for JFR and we came to the conclusion that it was
safe. Anyway, this is not different than before, so I will just leave it
out of this change for now.
The other thing is that C++ does not guarantee the order of how static
instances are initialized. Since the parallel collector uses static
instances of everything, including the GCTracer we may get conflicts
with the statically initialized GCId::UNDEFINED value. To work around
this I changed to a method called GCId::undefnied() that returns the
undefined GCId. That made it possible to have an instance method on GCId
to check if it is valid. Using that method (GCId::is_undefined())
removed the need of overloading the equals operators.
Here's a diff compared to the last webrev:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.04-05.diff/
Thanks,
Bengt
On 2014-06-05 22:58, Bengt Rutisson wrote:
>
> Hi Thomas,
>
> Thanks for looking at this!
>
> On 6/5/14 4:28 PM, Thomas Schatzl wrote:
>> Hi Bengt,
>>
>> On Wed, 2014-06-04 at 17:06 +0200, Bengt Rutisson wrote:
>>> Hi Erik,
>>>
>>> On 5/28/14 2:29 PM, Erik Helin wrote:
>>>> Hi Bengt,
>>>>
>>>> just a first quick general comment: would it make sense for GCId to be
>>>> in its own file or class, so the GC logging don't have to depend on
>>>> the GC trace framework?
>>> Good point.
>>>
>>> Here is an updated webrev where I separeted out GCId to its own file:
>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
>>>
>>> Here's just the diff compared to the earlier version:
>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
>>>
>>> Jesper, the updated webrev also contains the spelling mistake you
>>> noticed. Thanks for catching that!
>>>
>> two minor comments:
>>
>> - is it useful to check whether we are at a safepoint and running in the
>> VM thread when incrementing the gc id?
>
> Good idea. Added an assert for that.
>
>>
>> - also it would be nice to have some test case that checks for presence
>> of the numbers in log messages (and their absence if disabled).
>
> Yes, good point. I added a simple test.
>
> Here's an updated webrev:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.04/
>
> And here is the diff compared to the previous version:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.03-04.diff/
>
> Note that I also found a minor bug. The peek() method should not use
> "+1" the _next_id is already the next id, just like the name suggests
> ;). This only affect CMS and I noticed the problem since some IDs
> could sometimes be skipped. Now it works fine for CMS too.
>
> I also had to fix includes to make it compile without precompiled
> headers.
>
> Thanks,
> Bengt
>
>>
>> Thanks,
>> Thomas
>>
>>
>
From jesper.wilhelmsson at oracle.com Mon Jun 9 13:33:00 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 09 Jun 2014 15:33:00 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <5395A2DA.3000507@oracle.com>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com> <537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop> <538F35DE.1040802@oracle.com> <1401978537.2592.5.camel@cirrus>
<5390D9F9.2080202@oracle.com> <5395A2DA.3000507@oracle.com>
Message-ID: <5395B78C.4070908@oracle.com>
I like this version better than the last one :)
Reviewed.
/Jesper
Bengt Rutisson skrev 9/6/14 14:04:
>
> Hi again,
>
> Another updated webrev:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.05/
>
> Mainly two changes compared to the previous version. I had to remove the assert
> hat we only increment the GC id during a safepoint. That is not true for CMS,
> but I remember us looking thoroughly at that when we introduced the GC id for
> JFR and we came to the conclusion that it was safe. Anyway, this is not
> different than before, so I will just leave it out of this change for now.
>
> The other thing is that C++ does not guarantee the order of how static instances
> are initialized. Since the parallel collector uses static instances of
> everything, including the GCTracer we may get conflicts with the statically
> initialized GCId::UNDEFINED value. To work around this I changed to a method
> called GCId::undefnied() that returns the undefined GCId. That made it possible
> to have an instance method on GCId to check if it is valid. Using that method
> (GCId::is_undefined()) removed the need of overloading the equals operators.
>
> Here's a diff compared to the last webrev:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.04-05.diff/
>
> Thanks,
> Bengt
>
>
> On 2014-06-05 22:58, Bengt Rutisson wrote:
>>
>> Hi Thomas,
>>
>> Thanks for looking at this!
>>
>> On 6/5/14 4:28 PM, Thomas Schatzl wrote:
>>> Hi Bengt,
>>>
>>> On Wed, 2014-06-04 at 17:06 +0200, Bengt Rutisson wrote:
>>>> Hi Erik,
>>>>
>>>> On 5/28/14 2:29 PM, Erik Helin wrote:
>>>>> Hi Bengt,
>>>>>
>>>>> just a first quick general comment: would it make sense for GCId to be
>>>>> in its own file or class, so the GC logging don't have to depend on
>>>>> the GC trace framework?
>>>> Good point.
>>>>
>>>> Here is an updated webrev where I separeted out GCId to its own file:
>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
>>>>
>>>> Here's just the diff compared to the earlier version:
>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
>>>>
>>>> Jesper, the updated webrev also contains the spelling mistake you
>>>> noticed. Thanks for catching that!
>>>>
>>> two minor comments:
>>>
>>> - is it useful to check whether we are at a safepoint and running in the
>>> VM thread when incrementing the gc id?
>>
>> Good idea. Added an assert for that.
>>
>>>
>>> - also it would be nice to have some test case that checks for presence
>>> of the numbers in log messages (and their absence if disabled).
>>
>> Yes, good point. I added a simple test.
>>
>> Here's an updated webrev:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.04/
>>
>> And here is the diff compared to the previous version:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.03-04.diff/
>>
>> Note that I also found a minor bug. The peek() method should not use "+1" the
>> _next_id is already the next id, just like the name suggests ;). This only
>> affect CMS and I noticed the problem since some IDs could sometimes be
>> skipped. Now it works fine for CMS too.
>>
>> I also had to fix includes to make it compile without precompiled headers.
>>
>> Thanks,
>> Bengt
>>
>>>
>>> Thanks,
>>> Thomas
>>>
>>>
>>
>
From bengt.rutisson at oracle.com Mon Jun 9 13:34:05 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Mon, 09 Jun 2014 15:34:05 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <5395B78C.4070908@oracle.com>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com> <537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop> <538F35DE.1040802@oracle.com> <1401978537.2592.5.camel@cirrus>
<5390D9F9.2080202@oracle.com> <5395A2DA.3000507@oracle.com>
<5395B78C.4070908@oracle.com>
Message-ID: <5395B7CD.3070005@oracle.com>
On 2014-06-09 15:33, Jesper Wilhelmsson wrote:
> I like this version better than the last one :)
> Reviewed.
Thanks, Jesper!
Bengt
> /Jesper
>
> Bengt Rutisson skrev 9/6/14 14:04:
>>
>> Hi again,
>>
>> Another updated webrev:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.05/
>>
>> Mainly two changes compared to the previous version. I had to remove
>> the assert
>> hat we only increment the GC id during a safepoint. That is not true
>> for CMS,
>> but I remember us looking thoroughly at that when we introduced the
>> GC id for
>> JFR and we came to the conclusion that it was safe. Anyway, this is not
>> different than before, so I will just leave it out of this change for
>> now.
>>
>> The other thing is that C++ does not guarantee the order of how
>> static instances
>> are initialized. Since the parallel collector uses static instances of
>> everything, including the GCTracer we may get conflicts with the
>> statically
>> initialized GCId::UNDEFINED value. To work around this I changed to a
>> method
>> called GCId::undefnied() that returns the undefined GCId. That made
>> it possible
>> to have an instance method on GCId to check if it is valid. Using
>> that method
>> (GCId::is_undefined()) removed the need of overloading the equals
>> operators.
>>
>> Here's a diff compared to the last webrev:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.04-05.diff/
>>
>> Thanks,
>> Bengt
>>
>>
>> On 2014-06-05 22:58, Bengt Rutisson wrote:
>>>
>>> Hi Thomas,
>>>
>>> Thanks for looking at this!
>>>
>>> On 6/5/14 4:28 PM, Thomas Schatzl wrote:
>>>> Hi Bengt,
>>>>
>>>> On Wed, 2014-06-04 at 17:06 +0200, Bengt Rutisson wrote:
>>>>> Hi Erik,
>>>>>
>>>>> On 5/28/14 2:29 PM, Erik Helin wrote:
>>>>>> Hi Bengt,
>>>>>>
>>>>>> just a first quick general comment: would it make sense for GCId
>>>>>> to be
>>>>>> in its own file or class, so the GC logging don't have to depend on
>>>>>> the GC trace framework?
>>>>> Good point.
>>>>>
>>>>> Here is an updated webrev where I separeted out GCId to its own file:
>>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.02/
>>>>>
>>>>> Here's just the diff compared to the earlier version:
>>>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.01-02.diff/
>>>>>
>>>>> Jesper, the updated webrev also contains the spelling mistake you
>>>>> noticed. Thanks for catching that!
>>>>>
>>>> two minor comments:
>>>>
>>>> - is it useful to check whether we are at a safepoint and running
>>>> in the
>>>> VM thread when incrementing the gc id?
>>>
>>> Good idea. Added an assert for that.
>>>
>>>>
>>>> - also it would be nice to have some test case that checks for
>>>> presence
>>>> of the numbers in log messages (and their absence if disabled).
>>>
>>> Yes, good point. I added a simple test.
>>>
>>> Here's an updated webrev:
>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.04/
>>>
>>> And here is the diff compared to the previous version:
>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.03-04.diff/
>>>
>>> Note that I also found a minor bug. The peek() method should not use
>>> "+1" the
>>> _next_id is already the next id, just like the name suggests ;).
>>> This only
>>> affect CMS and I noticed the problem since some IDs could sometimes be
>>> skipped. Now it works fine for CMS too.
>>>
>>> I also had to fix includes to make it compile without precompiled
>>> headers.
>>>
>>> Thanks,
>>> Bengt
>>>
>>>>
>>>> Thanks,
>>>> Thomas
>>>>
>>>>
>>>
>>
From andrey.x.zakharov at oracle.com Mon Jun 9 14:59:47 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Mon, 09 Jun 2014 18:59:47 +0400
Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file
to JTwork/scratch/sun/hotspot
In-Reply-To: <537F33CB.5050505@oracle.com>
References: <536B7CF0.6010508@oracle.com> <536B9E36.6090802@oracle.com>
<536BA28D.7030808@oracle.com> <3503372.bSN5QEX8PY@mgerdin03>
<5371F734.6090809@oracle.com> <537CC81C.6010905@oracle.com>
<537DB9B0.8010200@oracle.com> <537F33CB.5050505@oracle.com>
Message-ID: <5395CBE3.5030502@oracle.com>
Hi, everybody
I have tested my changes on major platforms and found one bug, filed:
https://bugs.openjdk.java.net/browse/JDK-8046231
Also, i did another try to make ClassFileInstaller to copy all inner
classes within parent, but this fails for WhiteBox due its static
"registerNatives" dependency.
Please, review suggested changes:
- replace ClassFileInstaller and run/othervm with
"run/othervm/bootclasspath".
bootclasspath parameter for othervm adds-Xbootclasspath/a:
option with ${test.src} and ${test.classes}according to
http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/share/classes/com/sun/javatest/regtest/MainAction.java.
Is this suitable for our needs - give to test compiled WhiteBox?
- replace explicit -Xbootclasspath option values (".") in
ProcessBuilder invocations to ${test.classes} where WhiteBox has been
compiled.
Webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8011397
Thanks.
On 23.05.2014 15:40, Andrey Zakharov wrote:
>
> On 22.05.2014 12:47, Igor Ignatyev wrote:
>> Andrey,
>>
>> 1. You changed dozen of tests, have you tested your changes?
> Locally, aurora on the way.
>>
>> 2. Your changes of year in copyright is wrong. it has to be
>> $first_year, [$last_year, ], see Mark's email[1] for details.
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.html
> Thanks, fixed. will be uploaded soon.
>
>
>>
>> Igor
>>
>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote:
>>>
>>> On 13.05.2014 14:43, Andrey Zakharov wrote:
>>>> Hi
>>>> So here is trivial patch -
>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and adding
>>>> main/othervm/bootclasspath
>>>> where this needed
>>>>
>>>> Also, some tests are modified as
>>>> - "-Xbootclasspath/a:.",
>>>> + "-Xbootclasspath/a:" + System.getProperty("test.classes"),
>>>>
>>>> Thanks.
>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011397
>>> Thanks.
>>>
>>>>
>>>> On 09.05.2014 12:13, Mikael Gerdin wrote:
>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote:
>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime and gc lists.
>>>>>>
>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote:
>>>>>>> Andrey,
>>>>>>>
>>>>>>> I've CC'ed compiler and runtime mailing list, because you're
>>>>>>> changes
>>>>>>> affect test for other components as too.
>>>>>>>
>>>>>>> I don't like your solution (but I'm not a reviewer, so treat my
>>>>>>> words
>>>>>>> just as suggestion),
>>>>>>> because we'll have to write more meta information for each test
>>>>>>> and it
>>>>>>> is very easy to
>>>>>>> forget to install WhiteBoxPermission if you don't test your test
>>>>>>> with
>>>>>>> some security manager.
>>>>>>>
>>>>>>> From my point of view, it will be better to extend
>>>>>>> ClassFileInstaller
>>>>>>>
>>>>>>> so it will copy not only
>>>>>>> a class whose name was passed as an arguments, but also all inner
>>>>>>> classes of that class.
>>>>>>> And if someone want copy only specified class without inner
>>>>>>> classes,
>>>>>>> then some option
>>>>>>> could be added to ClassFileInstaller to force such behaviour.
>>>>> Perhaps this is a good time to get rid of ClassFileInstaller
>>>>> altogether?
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117
>>>>>
>>>>> The reason for its existence is that the WhiteBox class needs to be
>>>>> on the
>>>>> boot class path.
>>>>> If we can live with having all the test's classes on the boot class
>>>>> path then
>>>>> we could use the /bootclasspath option in jtreg as stated in the RFE.
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>> Thanks,
>>>>>>> Filipp.
>>>>>>>
>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote:
>>>>>>>> Hi!
>>>>>>>> Suggesting patch with fixes for
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397
>>>>>>>>
>>>>>>>> webrev:
>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397.tgz
>>>>>>>> patch:
>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397.WhiteBoxPer
>>>>>>>>
>>>>>>>>
>>>>>>>> mission
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks.
>>>>
>>>
>
From vladimir.kozlov at oracle.com Mon Jun 9 17:52:49 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 09 Jun 2014 10:52:49 -0700
Subject: [8u20] RFR(S)JDK-8034188 OSR methods may not be recompiled at
proper compilation level after deoptimization
In-Reply-To: <53957627.90907@oracle.com>
References: <53957627.90907@oracle.com>
Message-ID: <5395F471.9070604@oracle.com>
Looks good for backport.
Thanks,
Vladimir
On 6/9/14 1:53 AM, Nils Eliasson wrote:
> HI,
>
> I would like to request a 8u20 backport of JDK-8034188.
>
> The change where pushed to jdk 9 on 2014-03-11. Nightly testing has
> shown no problems. The change applies to 8u20 without conflicts.
>
> Master bug: https://bugs.openjdk.java.net/browse/JDK-8034188
> Webrev: http://cr.openjdk.java.net/~neliasso/8034188_8u20/webrev.01/
> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/47f00f3b3900
>
> Thanks,
> Nils
From david.holmes at oracle.com Tue Jun 10 03:39:02 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Jun 2014 13:39:02 +1000
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <5395848D.2010704@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com>
Message-ID: <53967DD6.50900@oracle.com>
Thanks Dima this looks okay to me.
David
On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
> Hi David,
>
> This is the updated version:
> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>
> I ran all applicable_* groups with the corresponding GC. No failures
> caused by conflicts.
>
> Thanks,
> Dima
>
> On 06.06.2014 9:47, David Holmes wrote:
>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>> Hi Dmitry,
>>>
>>> The existing nomenclature uses needs_xxx not requires_xxx, please
>>> maintain consistency with what exists.
>>
>> And yes I'm guilty of naming the groups needs_xxx while in the
>> comments I keep saying requires.
>>
>> David
>>
>>> Thanks,
>>> David
>>>
>>>
>>>
>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>> Hello,
>>>>
>>>> This fix introduces new jtreg groups to allow not running tests which
>>>> could conflict because of GC.
>>>> Please note, this solution is temporary for 2-3 months, unless jtreg
>>>> starts support the @requires tag
>>>> (CODETOOLS-7900307)
>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>
>>>> The change itself doesn't affect anything, it just allows to run group
>>>> of tests which doesn't require a specific gc.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>
>>>> Testing:
>>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC and
>>>> saw
>>>> only known issues not related to the conflict of flags.
>>>>
>>>> Thanks,
>>>> Dima
>
From daniel.daugherty at oracle.com Tue Jun 10 04:04:36 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 09 Jun 2014 22:04:36 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <53874908.5070805@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com>
<53874908.5070805@oracle.com>
Message-ID: <539683D4.9030508@oracle.com>
Greetings,
Nightly testing has revealed a bug in the test that reproduces
nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
Here's the webrev URL for the minor tweak to catch yet more
variation of the waiting pattern:
http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
Thanks to Vladimir K for reporting the test failure and for
providing the right details in the bug report.
Thanks, in advance, for any comments, questions or suggestions.
Dan
On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
> One more round of review after refactoring the test based on comments
> from David H and Serguei.
>
> Here's the webrev for this round:
>
> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>
> Had to change the default sample size from 30 -> 15 in order to
> get the test to pass reliably on Solaris SPARC JPRT machines.
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>
>
> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>> Zhengyu is tied up with some other work so I've taken on this fix.
>>
>> Here's the webrev URL for the next round:
>>
>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>
>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>> The new test has been run with the fix via JPRT and passes on all
>> JPRT platforms. The new test has also been run without the fix and
>> fails on most platforms. Since the default sample size is just 30,
>> it is possible to get 30 runs in a row without failing.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>> This is a simple fix for incorrect lock state.
>>>
>>> The timing on setting thread's pending monitor can result stack
>>> trace dump reporting incorrect lock state. The solution is to check
>>> the monitor's owner, if the owner is other than the current thread,
>>> then the monitor, is or is in process of being, set the pending
>>> monitor of current thread.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>
>>
>>
>
>
From daniel.daugherty at oracle.com Tue Jun 10 04:09:35 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 09 Jun 2014 22:09:35 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <539683D4.9030508@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com>
<53874908.5070805@oracle.com> <539683D4.9030508@oracle.com>
Message-ID: <539684FF.4070205@oracle.com>
I forgot to include a handy link to the bug:
https://bugs.openjdk.java.net/browse/JDK-8046287
Also, the new test was run for 3600 samples with the
-Xcomp and -XX:+DeoptimizeALot options which takes
about 45 minutes. With those options, the bad test
would fail in < 15 samples.
The new test was also run for 3600 samples in the
default config which takes about 42 minutes and did
not fail in that config.
Dan
On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> Nightly testing has revealed a bug in the test that reproduces
> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>
> Here's the webrev URL for the minor tweak to catch yet more
> variation of the waiting pattern:
>
> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>
> Thanks to Vladimir K for reporting the test failure and for
> providing the right details in the bug report.
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>
>
> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>> One more round of review after refactoring the test based on comments
>> from David H and Serguei.
>>
>> Here's the webrev for this round:
>>
>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>
>> Had to change the default sample size from 30 -> 15 in order to
>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>
>>> Here's the webrev URL for the next round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>
>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>> The new test has been run with the fix via JPRT and passes on all
>>> JPRT platforms. The new test has also been run without the fix and
>>> fails on most platforms. Since the default sample size is just 30,
>>> it is possible to get 30 runs in a row without failing.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>> This is a simple fix for incorrect lock state.
>>>>
>>>> The timing on setting thread's pending monitor can result stack
>>>> trace dump reporting incorrect lock state. The solution is to check
>>>> the monitor's owner, if the owner is other than the current thread,
>>>> then the monitor, is or is in process of being, set the pending
>>>> monitor of current thread.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>
>>>
>>>
>>
>>
>
From serguei.spitsyn at oracle.com Tue Jun 10 04:45:59 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 09 Jun 2014 21:45:59 -0700
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <539684FF.4070205@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<539683D4.9030508@oracle.com> <539684FF.4070205@oracle.com>
Message-ID: <53968D87.5010001@oracle.com>
It looks good to me.
It is still hard to guarantee there are no other unexpected thread states,
but running for 3600 samples with no fails is convincing.
Thanks,
Serguei
On 6/9/14 9:09 PM, Daniel D. Daugherty wrote:
> I forgot to include a handy link to the bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8046287
>
> Also, the new test was run for 3600 samples with the
> -Xcomp and -XX:+DeoptimizeALot options which takes
> about 45 minutes. With those options, the bad test
> would fail in < 15 samples.
>
> The new test was also run for 3600 samples in the
> default config which takes about 42 minutes and did
> not fail in that config.
>
> Dan
>
>
> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Nightly testing has revealed a bug in the test that reproduces
>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>
>> Here's the webrev URL for the minor tweak to catch yet more
>> variation of the waiting pattern:
>>
>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>
>> Thanks to Vladimir K for reporting the test failure and for
>> providing the right details in the bug report.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>> One more round of review after refactoring the test based on comments
>>> from David H and Serguei.
>>>
>>> Here's the webrev for this round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>
>>> Had to change the default sample size from 30 -> 15 in order to
>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>
>>>> Here's the webrev URL for the next round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>
>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>> The new test has been run with the fix via JPRT and passes on all
>>>> JPRT platforms. The new test has also been run without the fix and
>>>> fails on most platforms. Since the default sample size is just 30,
>>>> it is possible to get 30 runs in a row without failing.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>> This is a simple fix for incorrect lock state.
>>>>>
>>>>> The timing on setting thread's pending monitor can result stack
>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>> check the monitor's owner, if the owner is other than the current
>>>>> thread, then the monitor, is or is in process of being, set the
>>>>> pending monitor of current thread.
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
From david.holmes at oracle.com Tue Jun 10 07:12:23 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Jun 2014 17:12:23 +1000
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <53968D87.5010001@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com> <539683D4.9030508@oracle.com>
<539684FF.4070205@oracle.com> <53968D87.5010001@oracle.com>
Message-ID: <5396AFD7.8090900@oracle.com>
On 10/06/2014 2:45 PM, serguei.spitsyn at oracle.com wrote:
> It looks good to me.
> It is still hard to guarantee there are no other unexpected thread states,
I also wonder about that.
But I also question whether this is even possible:
253 // Example 2: (This example has not yet been spotted)
254 // "ContendingThread-1" #23 prio=5 os_prio=64
tid=0x0000000001556000 nid=0x30 waiting on condition [0xfffffd7fbf17e000]
255 // java.lang.Thread.State: BLOCKED (on object monitor)
I don't see how you can be blocking on an object monitor but suddenly
appear to be waiting on a condition ??
Looking at the comments in the bug, the Threads_lock is a mutex so it
uses ParkEvent::park, which is PlatformEvent::park which doesn't use
OSThreadWaitState.
David
-----
> but running for 3600 samples with no fails is convincing.
>
> Thanks,
> Serguei
>
> On 6/9/14 9:09 PM, Daniel D. Daugherty wrote:
>> I forgot to include a handy link to the bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>
>> Also, the new test was run for 3600 samples with the
>> -Xcomp and -XX:+DeoptimizeALot options which takes
>> about 45 minutes. With those options, the bad test
>> would fail in < 15 samples.
>>
>> The new test was also run for 3600 samples in the
>> default config which takes about 42 minutes and did
>> not fail in that config.
>>
>> Dan
>>
>>
>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> Nightly testing has revealed a bug in the test that reproduces
>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>
>>> Here's the webrev URL for the minor tweak to catch yet more
>>> variation of the waiting pattern:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>
>>> Thanks to Vladimir K for reporting the test failure and for
>>> providing the right details in the bug report.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>> One more round of review after refactoring the test based on comments
>>>> from David H and Serguei.
>>>>
>>>> Here's the webrev for this round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>
>>>> Had to change the default sample size from 30 -> 15 in order to
>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>
>>>>> Here's the webrev URL for the next round:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>
>>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>> it is possible to get 30 runs in a row without failing.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>> This is a simple fix for incorrect lock state.
>>>>>>
>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>>> check the monitor's owner, if the owner is other than the current
>>>>>> thread, then the monitor, is or is in process of being, set the
>>>>>> pending monitor of current thread.
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
From stefan.karlsson at oracle.com Tue Jun 10 08:21:05 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Jun 2014 10:21:05 +0200
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC706B@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
<53902C7E.5010108@oracle.com>
<4295855A5C1DE049A61835A1887419CC2CEC706B@DEWDFEMB12A.global.corp.sap>
Message-ID: <5396BFF1.7080305@oracle.com>
On 2014-06-05 22:23, Lindenmaier, Goetz wrote:
> Hi Stefan,
>
> thanks for the thorough review!
>
>> Thanks again for cleaning up the include files.
> I checked the other includes, I would like to do this for os_<os>.inline.hpp, too.
> That include cascade is shorter, but used in around 30 files.
> Other more prominent cascades are
> bytes_<cpu>.hpp (12 cascades),
> ad_<cpu>.hpp (10 cascades),
> nativeInst_<cpu>.hpp (8)
> vmreg.inline_<cpu>.hpp (7)
> As we have another 3 cpus (zArch, parisc, ia64), that would clean up our code
> nicely ;)
>
> Back to this change:
>
> I moved the Atomics in StringDedup.hpp as you requested.
> I removed the include in markSweep.inline.hpp.
> I moved the include in oop.pcgc.inline.hpp up.
> I moved the debug methods in gcLocker.hpp to the cpp file.
>
>> This is a lot of noise just to get rid of a call to the the
>> CompiledICHolder constructor in product builds. Is it really worth it?
> I think not. Moved to cpp file.
>
> About adding the header to precompiled.hpp: I don't really care,
> I just follow the current pattern. As there were no other comments
> on your request in the last change, I removed it this time.
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.01
Thanks.
Looks good to me.
StefanK
>
> Best regards,
> Goetz.
>
>
> -----Original Message-----
> From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
> Sent: Donnerstag, 5. Juni 2014 10:38
> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
>
> Hi Goetz,
>
> Thanks again for cleaning up the include files.
>
> On 2014-06-04 15:59, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I would like to do another change cleaning up the includes of
>> .inline.hpp files from the os_cpu directories.
>>
>> Please review and test this change. I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.hpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.cpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupQueue.cpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp.udiff.html
>
> I think it would be good to move the Atomic calls out from the
> g1StringDedup.hpp to g1StringDedup.cpp. I talked to Per, the author of
> StringDedup, and he would be fine with that move.
> I moved the debug methods in gcLocker.hpp to the cpp file.
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.frames.html
>
> 32 #if INCLUDE_ALL_GCS
> 33 #include "gc_implementation/g1/g1StringDedup.hpp"
> 34 #include "gc_implementation/parallelScavenge/psParallelCompact.hpp"
> 35 #include "runtime/atomic.inline.hpp"
> 36 #endif // INCLUDE_ALL_GCS
>
> Why was this include added? Was it becuase g1StringDedup.hpp was added?
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/mutableSpace.cpp.frames.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/oop.pcgc.inline.hpp.frames.html
>
> 25 #include "precompiled.hpp"
> 26 #include "utilities/macros.hpp"
> 27 #if INCLUDE_ALL_GCS
> 28 #include "gc_implementation/shared/mutableSpace.hpp"
> 29 #include "gc_implementation/shared/spaceDecorator.hpp"
> 30 #include "oops/oop.inline.hpp"
> 31 #include "runtime/safepoint.hpp"
> 32 #include "runtime/thread.hpp"
> 33 #endif // INCLUDE_ALL_GCS
> 34 #include "runtime/atomic.inline.hpp"
>
> Could you place the new includes together with the includes before the
> INCLUDE_ALL_GCS block?
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.hpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.inline.hpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/runtime/safepoint.cpp.udiff.html
>
> + inline static void increment_debug_jni_lock_count();
> + inline static void decrement_debug_jni_lock_count();
>
> This is debugging code, so it would be better to move it to the .cpp file.
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/compiledICHolder.hpp.udiff.html
>
> 54 #ifdef ASSERT
> 55 CompiledICHolder(Method* method, Klass* klass);
> 56 #else
> 57 CompiledICHolder(Method* method, Klass* klass)
> 58 : _holder_method(method), _holder_klass(klass) {};
> 59 #endif
> 60
> 61 ~CompiledICHolder() NOT_DEBUG_RETURN;
>
> This is a lot of noise just to get rid of a call to the the
> CompiledICHolder constructor in product builds. Is it really worth it?
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/precompiled/precompiled.hpp.udiff.html
>
> # include "runtime/atomic.hpp"
> +# include "runtime/atomic.inline.hpp"
>
> I still think this is a bad idea. It will just make it more likely that
> someone building with precompiled headers will forget to include
> atomic.inline.hpp, and we would have to clean it up later when we found
> out that it breaks some platform outside of Oracle's test matrix.
>
> thanks,
> StefanK
>
>> This change improves the usage of the umbrella header atomic.inline.hpp.
>> It removes includes of this header in files where it's not needed,
>> and adds it in all .cpp and .inline.hpp files where a method of
>> Atomic declared 'inline' is used.
>>
>> Also, the change moves some calls to such methods from .hpp files to
>> .inline.hpp files. In case of ASSERT code it moves the calls
>> to .cpp files.
>>
>> A row of headers still contain calls to inline methods of Atomic,
>> which I don't want to move as no appropriate .inline.hpp file is existing:
>>
>> src/share/vm/compiler/compileBroker.hpp
>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
>> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
>> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
>> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
>> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
>> src/share/vm/memory/specialized_oop_closures.hpp
>> src/share/vm/oops/methodData.hpp
>> src/share/vm/runtime/safepoint.hpp
>> src/share/vm/services/lowMemoryDetector.hpp
>> src/share/vm/services/memTracker.hpp
>> src/share/vm/utilities/taskqueue.hpp
>>
>> I compiled and tested this without precompiled headers on
>> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
>> in opt, dbg and fastdbg versions.
>>
>> Best regards,
>> Goetz.
From thomas.schatzl at oracle.com Tue Jun 10 09:09:03 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 10 Jun 2014 11:09:03 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <5395A2DA.3000507@oracle.com>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com>
<537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop>
<538F35DE.1040802@oracle.com> <1401978537.2592.5.camel@cirrus>
<5390D9F9.2080202@oracle.com> <5395A2DA.3000507@oracle.com>
Message-ID: <1402391343.2588.15.camel@cirrus>
Hi,
On Mon, 2014-06-09 at 14:04 +0200, Bengt Rutisson wrote:
> Hi again,
>
> Another updated webrev:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.05/
>
> Mainly two changes compared to the previous version. I had to remove the
> assert hat we only increment the GC id during a safepoint. That is not
> true for CMS, but I remember us looking thoroughly at that when we
> introduced the GC id for JFR and we came to the conclusion that it was
> safe. Anyway, this is not different than before, so I will just leave it
> out of this change for now.
Okay.
>
> The other thing is that C++ does not guarantee the order of how static
> instances are initialized. Since the parallel collector uses static
> instances of everything, including the GCTracer we may get conflicts
> with the statically initialized GCId::UNDEFINED value. To work around
> this I changed to a method called GCId::undefnied() that returns the
> undefined GCId. That made it possible to have an instance method on GCId
> to check if it is valid. Using that method (GCId::is_undefined())
> removed the need of overloading the equals operators.
>
> Here's a diff compared to the last webrev:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.04-05.diff/
Okay.
Regarding the test and possible backporting: the test currently assumes
that gc id printing is on by default. Wouldn't it be better to specify
+/-PrintGCId in the these tests to make sure it also works with
different default settings, and possibly one run checking default
settings?
You mentioned somewhere that you want to backport this change to 8u with
the default value of PrintGCid to be false (iirc) too.
Thanks,
Thomas
From bengt.rutisson at oracle.com Tue Jun 10 12:37:40 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Tue, 10 Jun 2014 14:37:40 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <1402391343.2588.15.camel@cirrus>
References: <537C7264.70200@oracle.com>
<537DAA00.2010104@oracle.com> <537ED5FC.6080702@oracle.com>
<2198629.dbW8eWbo0l@ehelin-desktop> <538F35DE.1040802@oracle.com>
<1401978537.2592.5.camel@cirrus> <5390D9F9.2080202@oracle.com>
<5395A2DA.3000507@oracle.com> <1402391343.2588.15.camel@cirrus>
Message-ID: <5396FC14.5010705@oracle.com>
Hi Thomas,
Thanks for looking at this again!
On 2014-06-10 11:09, Thomas Schatzl wrote:
> Hi,
>
> On Mon, 2014-06-09 at 14:04 +0200, Bengt Rutisson wrote:
>> Hi again,
>>
>> Another updated webrev:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.05/
>>
>> Mainly two changes compared to the previous version. I had to remove the
>> assert hat we only increment the GC id during a safepoint. That is not
>> true for CMS, but I remember us looking thoroughly at that when we
>> introduced the GC id for JFR and we came to the conclusion that it was
>> safe. Anyway, this is not different than before, so I will just leave it
>> out of this change for now.
> Okay.
>
>> The other thing is that C++ does not guarantee the order of how static
>> instances are initialized. Since the parallel collector uses static
>> instances of everything, including the GCTracer we may get conflicts
>> with the statically initialized GCId::UNDEFINED value. To work around
>> this I changed to a method called GCId::undefnied() that returns the
>> undefined GCId. That made it possible to have an instance method on GCId
>> to check if it is valid. Using that method (GCId::is_undefined())
>> removed the need of overloading the equals operators.
>>
>> Here's a diff compared to the last webrev:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.04-05.diff/
> Okay.
>
> Regarding the test and possible backporting: the test currently assumes
> that gc id printing is on by default. Wouldn't it be better to specify
> +/-PrintGCId in the these tests to make sure it also works with
> different default settings, and possibly one run checking default
> settings?
Good point. I updated the test:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/test/gc/logging/TestGCId.java.html
Full new webrev (only the test has changed):
http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/
> You mentioned somewhere that you want to backport this change to 8u with
> the default value of PrintGCid to be false (iirc) too.
Right. That is my plan. I will need to send out a separate review for
that since I will do a code change (the default value in globals.hpp),
so we can discuss the details during that review. With the new test the
only required change is to switch verify method for the default case.
Bengt
>
> Thanks,
> Thomas
>
>
From daniel.daugherty at oracle.com Tue Jun 10 12:44:45 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 10 Jun 2014 06:44:45 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <53968D87.5010001@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<539683D4.9030508@oracle.com> <539684FF.4070205@oracle.com>
<53968D87.5010001@oracle.com>
Message-ID: <5396FDBD.8090509@oracle.com>
Serguei,
Thanks for the fast review! I concur that there is no guarantee
that we won't run into more unexpected thread states. I took a
look at src/share/vm/runtime/osThread.hpp and none of the other
states appear to be applicable for the test threads that we
create and use in the test.
As David H is fond of saying lately, the proof is in the testing.
Dan
On 6/9/14 10:45 PM, serguei.spitsyn at oracle.com wrote:
> It looks good to me.
> It is still hard to guarantee there are no other unexpected thread
> states,
> but running for 3600 samples with no fails is convincing.
>
> Thanks,
> Serguei
>
> On 6/9/14 9:09 PM, Daniel D. Daugherty wrote:
>> I forgot to include a handy link to the bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>
>> Also, the new test was run for 3600 samples with the
>> -Xcomp and -XX:+DeoptimizeALot options which takes
>> about 45 minutes. With those options, the bad test
>> would fail in < 15 samples.
>>
>> The new test was also run for 3600 samples in the
>> default config which takes about 42 minutes and did
>> not fail in that config.
>>
>> Dan
>>
>>
>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> Nightly testing has revealed a bug in the test that reproduces
>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>
>>> Here's the webrev URL for the minor tweak to catch yet more
>>> variation of the waiting pattern:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>
>>> Thanks to Vladimir K for reporting the test failure and for
>>> providing the right details in the bug report.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>> One more round of review after refactoring the test based on comments
>>>> from David H and Serguei.
>>>>
>>>> Here's the webrev for this round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>
>>>> Had to change the default sample size from 30 -> 15 in order to
>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>
>>>>> Here's the webrev URL for the next round:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>
>>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>> it is possible to get 30 runs in a row without failing.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>> This is a simple fix for incorrect lock state.
>>>>>>
>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>>> check the monitor's owner, if the owner is other than the current
>>>>>> thread, then the monitor, is or is in process of being, set the
>>>>>> pending monitor of current thread.
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
From daniel.daugherty at oracle.com Tue Jun 10 12:49:31 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 10 Jun 2014 06:49:31 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <5396AFD7.8090900@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com> <539683D4.9030508@oracle.com>
<539684FF.4070205@oracle.com> <53968D87.5010001@oracle.com>
<5396AFD7.8090900@oracle.com>
Message-ID: <5396FEDB.8040509@oracle.com>
David,
Thanks for the fast code review!
On 6/10/14 1:12 AM, David Holmes wrote:
> On 10/06/2014 2:45 PM, serguei.spitsyn at oracle.com wrote:
>> It looks good to me.
>> It is still hard to guarantee there are no other unexpected thread
>> states,
>
> I also wonder about that.
>
> But I also question whether this is even possible:
>
> 253 // Example 2: (This example has not yet been spotted)
> 254 // "ContendingThread-1" #23 prio=5 os_prio=64
> tid=0x0000000001556000 nid=0x30 waiting on condition [0xfffffd7fbf17e000]
> 255 // java.lang.Thread.State: BLOCKED (on object monitor)
>
> I don't see how you can be blocking on an object monitor but suddenly
> appear to be waiting on a condition ??
That would be why I said "This example has not yet been spotted".
Yes, I'm being paranoid, but you knew that anyway :-)
> Looking at the comments in the bug, the Threads_lock is a mutex so it
> uses ParkEvent::park, which is PlatformEvent::park which doesn't use
> OSThreadWaitState.
I'll chase this down with a native stack trace to see where
we are exactly. I don't know if I'll be able to get that done
today...
Dan
>
> David
> -----
>
>
>> but running for 3600 samples with no fails is convincing.
>>
>> Thanks,
>> Serguei
>>
>> On 6/9/14 9:09 PM, Daniel D. Daugherty wrote:
>>> I forgot to include a handy link to the bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>>
>>> Also, the new test was run for 3600 samples with the
>>> -Xcomp and -XX:+DeoptimizeALot options which takes
>>> about 45 minutes. With those options, the bad test
>>> would fail in < 15 samples.
>>>
>>> The new test was also run for 3600 samples in the
>>> default config which takes about 42 minutes and did
>>> not fail in that config.
>>>
>>> Dan
>>>
>>>
>>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> Nightly testing has revealed a bug in the test that reproduces
>>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>>
>>>> Here's the webrev URL for the minor tweak to catch yet more
>>>> variation of the waiting pattern:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>>
>>>> Thanks to Vladimir K for reporting the test failure and for
>>>> providing the right details in the bug report.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>>> One more round of review after refactoring the test based on comments
>>>>> from David H and Serguei.
>>>>>
>>>>> Here's the webrev for this round:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>>
>>>>> Had to change the default sample size from 30 -> 15 in order to
>>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>>
>>>>>> Here's the webrev URL for the next round:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>>
>>>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>>> it is possible to get 30 runs in a row without failing.
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>>> This is a simple fix for incorrect lock state.
>>>>>>>
>>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>>>> check the monitor's owner, if the owner is other than the current
>>>>>>> thread, then the monitor, is or is in process of being, set the
>>>>>>> pending monitor of current thread.
>>>>>>>
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
From igor.ignatyev at oracle.com Tue Jun 10 15:43:34 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 10 Jun 2014 19:43:34 +0400
Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file
to JTwork/scratch/sun/hotspot
In-Reply-To: <5395CBE3.5030502@oracle.com>
References: <536B7CF0.6010508@oracle.com> <536B9E36.6090802@oracle.com>
<536BA28D.7030808@oracle.com> <3503372.bSN5QEX8PY@mgerdin03>
<5371F734.6090809@oracle.com> <537CC81C.6010905@oracle.com>
<537DB9B0.8010200@oracle.com> <537F33CB.5050505@oracle.com>
<5395CBE3.5030502@oracle.com>
Message-ID: <539727A6.5030307@oracle.com>
Andrey,
I don't like this idea, since it completely changes the tests.
'run/othervm/bootclasspath' adds all paths from CP to BCP, so the tests
whose main idea was testing WB methods themselves (sanity,
compiler/whitebox, ...) don't check that it's possible to use WB when
the application isn't in BCP.
Igor
On 06/09/2014 06:59 PM, Andrey Zakharov wrote:
> Hi, everybody
> I have tested my changes on major platforms and found one bug, filed:
> https://bugs.openjdk.java.net/browse/JDK-8046231
> Also, i did another try to make ClassFileInstaller to copy all inner
> classes within parent, but this fails for WhiteBox due its static
> "registerNatives" dependency.
>
> Please, review suggested changes:
> - replace ClassFileInstaller and run/othervm with
> "run/othervm/bootclasspath".
> bootclasspath parameter for othervm adds-Xbootclasspath/a:
> option with ${test.src} and ${test.classes}according to
> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/share/classes/com/sun/javatest/regtest/MainAction.java.
> Is this suitable for our needs - give to test compiled WhiteBox?
> - replace explicit -Xbootclasspath option values (".") in
> ProcessBuilder invocations to ${test.classes} where WhiteBox has been
> compiled.
>
> Webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8011397
> Thanks.
>
>
> On 23.05.2014 15:40, Andrey Zakharov wrote:
>>
>> On 22.05.2014 12:47, Igor Ignatyev wrote:
>>> Andrey,
>>>
>>> 1. You changed dozen of tests, have you tested your changes?
>> Locally, aurora on the way.
>>>
>>> 2. Your changes of year in copyright is wrong. it has to be
>>> $first_year, [$last_year, ], see Mark's email[1] for details.
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.html
>> Thanks, fixed. will be uploaded soon.
>>
>>
>>>
>>> Igor
>>>
>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote:
>>>>
>>>> On 13.05.2014 14:43, Andrey Zakharov wrote:
>>>>> Hi
>>>>> So here is trivial patch -
>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and adding
>>>>> main/othervm/bootclasspath
>>>>> where this needed
>>>>>
>>>>> Also, some tests are modified as
>>>>> - "-Xbootclasspath/a:.",
>>>>> + "-Xbootclasspath/a:" + System.getProperty("test.classes"),
>>>>>
>>>>> Thanks.
>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011397
>>>> Thanks.
>>>>
>>>>>
>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote:
>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote:
>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime and gc lists.
>>>>>>>
>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote:
>>>>>>>> Andrey,
>>>>>>>>
>>>>>>>> I've CC'ed compiler and runtime mailing list, because you're
>>>>>>>> changes
>>>>>>>> affect test for other components as too.
>>>>>>>>
>>>>>>>> I don't like your solution (but I'm not a reviewer, so treat my
>>>>>>>> words
>>>>>>>> just as suggestion),
>>>>>>>> because we'll have to write more meta information for each test
>>>>>>>> and it
>>>>>>>> is very easy to
>>>>>>>> forget to install WhiteBoxPermission if you don't test your test
>>>>>>>> with
>>>>>>>> some security manager.
>>>>>>>>
>>>>>>>> From my point of view, it will be better to extend
>>>>>>>> ClassFileInstaller
>>>>>>>>
>>>>>>>> so it will copy not only
>>>>>>>> a class whose name was passed as an arguments, but also all inner
>>>>>>>> classes of that class.
>>>>>>>> And if someone want copy only specified class without inner
>>>>>>>> classes,
>>>>>>>> then some option
>>>>>>>> could be added to ClassFileInstaller to force such behaviour.
>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller
>>>>>> altogether?
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117
>>>>>>
>>>>>> The reason for its existence is that the WhiteBox class needs to be
>>>>>> on the
>>>>>> boot class path.
>>>>>> If we can live with having all the test's classes on the boot class
>>>>>> path then
>>>>>> we could use the /bootclasspath option in jtreg as stated in the RFE.
>>>>>>
>>>>>> /Mikael
>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Filipp.
>>>>>>>>
>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote:
>>>>>>>>> Hi!
>>>>>>>>> Suggesting patch with fixes for
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397
>>>>>>>>>
>>>>>>>>> webrev:
>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397.tgz
>>>>>>>>> patch:
>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397.WhiteBoxPer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> mission
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>
>>>>
>>
>
From dmitry.fazunenko at oracle.com Tue Jun 10 17:03:47 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Tue, 10 Jun 2014 21:03:47 +0400
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <53967DD6.50900@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
Message-ID: <53973A73.8080507@oracle.com>
Hi David,
thanks for the prompt review.
Would you mind if the "all_hs_tests" group includes "testlibrary/" and
"testlibrary_tests/"?
The updated webrev:
http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
Thanks,
Dima
On 10.06.2014 7:39, David Holmes wrote:
> Thanks Dima this looks okay to me.
>
> David
>
> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>> Hi David,
>>
>> This is the updated version:
>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>
>> I ran all applicable_* groups with the corresponding GC. No failures
>> caused by conflicts.
>>
>> Thanks,
>> Dima
>>
>> On 06.06.2014 9:47, David Holmes wrote:
>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>> Hi Dmitry,
>>>>
>>>> The existing nomenclature uses needs_xxx not requires_xxx, please
>>>> maintain consistency with what exists.
>>>
>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>> comments I keep saying requires.
>>>
>>> David
>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>
>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>> Hello,
>>>>>
>>>>> This fix introduces new jtreg groups to allow not running tests which
>>>>> could conflict because of GC.
>>>>> Please note, this solution is temporary for 2-3 months, unless jtreg
>>>>> starts support the @requires tag
>>>>> (CODETOOLS-7900307)
>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>
>>>>> The change itself doesn't affect anything, it just allows to run
>>>>> group
>>>>> of tests which doesn't require a specific gc.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>
>>>>> Testing:
>>>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC and
>>>>> saw
>>>>> only known issues not related to the conflict of flags.
>>>>>
>>>>> Thanks,
>>>>> Dima
>>
From thomas.schatzl at oracle.com Tue Jun 10 18:24:36 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 10 Jun 2014 20:24:36 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <5396FC14.5010705@oracle.com>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com>
<537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop>
<538F35DE.1040802@oracle.com> <1401978537.2592.5.camel@cirrus>
<5390D9F9.2080202@oracle.com> <5395A2DA.3000507@oracle.com>
<1402391343.2588.15.camel@cirrus> <5396FC14.5010705@oracle.com>
Message-ID: <1402424676.2701.7.camel@cirrus>
Hi,
On Tue, 2014-06-10 at 14:37 +0200, Bengt Rutisson wrote:
> Hi Thomas,
>
> Thanks for looking at this again!
> >
> > Regarding the test and possible backporting: the test currently assumes
> > that gc id printing is on by default. Wouldn't it be better to specify
> > +/-PrintGCId in the these tests to make sure it also works with
> > different default settings, and possibly one run checking default
> > settings?
>
> Good point. I updated the test:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/test/gc/logging/TestGCId.java.html
>
> Full new webrev (only the test has changed):
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/
>
> > You mentioned somewhere that you want to backport this change to 8u with
> > the default value of PrintGCid to be false (iirc) too.
>
> Right. That is my plan. I will need to send out a separate review for
> that since I will do a code change (the default value in globals.hpp),
> so we can discuss the details during that review. With the new test the
> only required change is to switch verify method for the default case.
Okay. Looks good to me.
Thomas
From mikael.vidstedt at oracle.com Wed Jun 11 00:11:03 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 10 Jun 2014 17:11:03 -0700
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value
for hotspot ARCH
Message-ID: <53979E97.1040609@oracle.com>
All,
I need some feedback and comments on the below fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
Background:
When configuring the hotspot build the build system sets up the ARCH
variable to reflect the target cpu. Currently the value is initialized
to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. For
example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The
goal in the new (JDK) build system is to have the "legacy" value
gradually removed in favor of the other variables.
Discussion:
The two candidate variables to base ARCH on are as far as I can tell
OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
with ARCH_DATA_MODEL/LP64 that information should be enough for the
Hotspot build system to do its thing. Note: ARCH is currently ignored on
solaris and bsd - it's overridden at the top of the respective
make/<os>/makefiles/defs.make files.
Before I go too far with this though I'd like to get some feedback on
whether or not this is the right approach and what the exact value
should be. Depending on the outcome of that the Hotspot build system may
have to be updated for some platforms to support the new value(s).
Thanks,
Mikael
From david.holmes at oracle.com Wed Jun 11 02:45:58 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jun 2014 12:45:58 +1000
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <53979E97.1040609@oracle.com>
References: <53979E97.1040609@oracle.com>
Message-ID: <5397C2E6.6080603@oracle.com>
Hi Mikael,
This seems a reasonable proposal to me. We have an over-abundance of
"arch" variables and values, so reducing that is a good aim.
As you note the main flow-on effect here is that the hotspot makefiles
have to be updated for the cases where OPENJDK_TARGET_CPU_ARCH and
OPENJDK_TARGET_CPU_LEGACY differ so that it still sets LIBARCH,
BUILDARCH, SRCARCH correctly. I think only x86 has that issue.
Wouldn't it be nice if we could get rid of i386, i586, i686 etc both
internally and in the build artifacts and bundles!
Cheers,
David
On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>
> All,
>
> I need some feedback and comments on the below fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>
> Background:
>
> When configuring the hotspot build the build system sets up the ARCH
> variable to reflect the target cpu. Currently the value is initialized
> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. For
> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The
> goal in the new (JDK) build system is to have the "legacy" value
> gradually removed in favor of the other variables.
>
> Discussion:
>
> The two candidate variables to base ARCH on are as far as I can tell
> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
> with ARCH_DATA_MODEL/LP64 that information should be enough for the
> Hotspot build system to do its thing. Note: ARCH is currently ignored on
> solaris and bsd - it's overridden at the top of the respective
> make/<os>/makefiles/defs.make files.
>
> Before I go too far with this though I'd like to get some feedback on
> whether or not this is the right approach and what the exact value
> should be. Depending on the outcome of that the Hotspot build system may
> have to be updated for some platforms to support the new value(s).
>
> Thanks,
> Mikael
>
From daniel.daugherty at oracle.com Wed Jun 11 04:35:12 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 10 Jun 2014 22:35:12 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <5396FEDB.8040509@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com> <539683D4.9030508@oracle.com>
<539684FF.4070205@oracle.com> <53968D87.5010001@oracle.com>
<5396AFD7.8090900@oracle.com> <5396FEDB.8040509@oracle.com>
Message-ID: <5397DC80.3020908@oracle.com>
On 6/10/14 6:49 AM, Daniel D. Daugherty wrote:
> David,
>
> Thanks for the fast code review!
>
>
> On 6/10/14 1:12 AM, David Holmes wrote:
>> On 10/06/2014 2:45 PM, serguei.spitsyn at oracle.com wrote:
>>> It looks good to me.
>>> It is still hard to guarantee there are no other unexpected thread
>>> states,
>>
>> I also wonder about that.
>>
>> But I also question whether this is even possible:
>>
>> 253 // Example 2: (This example has not yet been spotted)
>> 254 // "ContendingThread-1" #23 prio=5 os_prio=64
>> tid=0x0000000001556000 nid=0x30 waiting on condition
>> [0xfffffd7fbf17e000]
>> 255 // java.lang.Thread.State: BLOCKED (on object monitor)
>>
>> I don't see how you can be blocking on an object monitor but suddenly
>> appear to be waiting on a condition ??
>
> That would be why I said "This example has not yet been spotted".
> Yes, I'm being paranoid, but you knew that anyway :-)
>
>
>> Looking at the comments in the bug, the Threads_lock is a mutex so it
>> uses ParkEvent::park, which is PlatformEvent::park which doesn't use
>> OSThreadWaitState.
>
> I'll chase this down with a native stack trace to see where
> we are exactly. I don't know if I'll be able to get that done
> today...
So I chased this down to the VM_Deopt call that results from
the -XX:+DeoptimizeALot option. So yes, my original comment
about Parker::park() is wrong, but the bug now has the gory
details of how we really got there...
Dan
>
> Dan
>
>
>>
>> David
>> -----
>>
>>
>>> but running for 3600 samples with no fails is convincing.
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 6/9/14 9:09 PM, Daniel D. Daugherty wrote:
>>>> I forgot to include a handy link to the bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>>>
>>>> Also, the new test was run for 3600 samples with the
>>>> -Xcomp and -XX:+DeoptimizeALot options which takes
>>>> about 45 minutes. With those options, the bad test
>>>> would fail in < 15 samples.
>>>>
>>>> The new test was also run for 3600 samples in the
>>>> default config which takes about 42 minutes and did
>>>> not fail in that config.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> Nightly testing has revealed a bug in the test that reproduces
>>>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>>>
>>>>> Here's the webrev URL for the minor tweak to catch yet more
>>>>> variation of the waiting pattern:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>>>
>>>>> Thanks to Vladimir K for reporting the test failure and for
>>>>> providing the right details in the bug report.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>>>> One more round of review after refactoring the test based on
>>>>>> comments
>>>>>> from David H and Serguei.
>>>>>>
>>>>>> Here's the webrev for this round:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>>>
>>>>>> Had to change the default sample size from 30 -> 15 in order to
>>>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>>>
>>>>>>> Here's the webrev URL for the next round:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>>>
>>>>>>> The fix has been tested with vm.quick on all Aurora Adhoc
>>>>>>> platforms.
>>>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>>>> it is possible to get 30 runs in a row without failing.
>>>>>>>
>>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>>>> This is a simple fix for incorrect lock state.
>>>>>>>>
>>>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>>>>> check the monitor's owner, if the owner is other than the current
>>>>>>>> thread, then the monitor, is or is in process of being, set the
>>>>>>>> pending monitor of current thread.
>>>>>>>>
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
>
>
From mikael.vidstedt at oracle.com Wed Jun 11 05:53:59 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 10 Jun 2014 22:53:59 -0700
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <5397C2E6.6080603@oracle.com>
References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com>
Message-ID: <5397EEF7.5050006@oracle.com>
David,
Thanks for the feedback. Essentially the logic in the
make/<os>/makefiles/defs.make files needs to recognize and deal with two
different use cases:
1. ARCH being set by the JDK build system to the value of
OPENJDK_TARGET_CPU_ARCH, or
2. no ARCH being set, in which case it needs to be populated - typically
from uname
Since Solaris and bsd both override ARCH they do not care about
OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
Linux/x86 is where most of the difference (and confusion) is, but I
think aix/ppc64 will also change slightly since the ARCH value will go
from ppc64 to ppc. I've tried to make the relevant changes, but I cannot
verify that they actually work. cc:ing the ppc-aix list in the hope that
somebody can help out with that.
Summing it up, I have the following two webrevs:
top:
http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
hotspot:
http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
With these changes I can build the normal platforms, but more
verification is needed - esp. building hotspot only. Meanwhile feedback
is much appreciated!
Cheers,
Mikael
On 2014-06-10 19:45, David Holmes wrote:
> Hi Mikael,
>
> This seems a reasonable proposal to me. We have an over-abundance of
> "arch" variables and values, so reducing that is a good aim.
>
> As you note the main flow-on effect here is that the hotspot makefiles
> have to be updated for the cases where OPENJDK_TARGET_CPU_ARCH and
> OPENJDK_TARGET_CPU_LEGACY differ so that it still sets LIBARCH,
> BUILDARCH, SRCARCH correctly. I think only x86 has that issue.
>
> Wouldn't it be nice if we could get rid of i386, i586, i686 etc both
> internally and in the build artifacts and bundles!
>
> Cheers,
> David
>
> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>
>> All,
>>
>> I need some feedback and comments on the below fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>> Webrev:
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>
>> Background:
>>
>> When configuring the hotspot build the build system sets up the ARCH
>> variable to reflect the target cpu. Currently the value is initialized
>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. For
>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The
>> goal in the new (JDK) build system is to have the "legacy" value
>> gradually removed in favor of the other variables.
>>
>> Discussion:
>>
>> The two candidate variables to base ARCH on are as far as I can tell
>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>> Hotspot build system to do its thing. Note: ARCH is currently ignored on
>> solaris and bsd - it's overridden at the top of the respective
>> make/<os>/makefiles/defs.make files.
>>
>> Before I go too far with this though I'd like to get some feedback on
>> whether or not this is the right approach and what the exact value
>> should be. Depending on the outcome of that the Hotspot build system may
>> have to be updated for some platforms to support the new value(s).
>>
>> Thanks,
>> Mikael
>>
From david.holmes at oracle.com Wed Jun 11 09:05:49 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jun 2014 19:05:49 +1000
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <53973A73.8080507@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
<53973A73.8080507@oracle.com>
Message-ID: <53981BED.4030907@oracle.com>
On 11/06/2014 3:03 AM, Dmitry Fazunenko wrote:
> Hi David,
>
> thanks for the prompt review.
> Would you mind if the "all_hs_tests" group includes "testlibrary/" and
> "testlibrary_tests/"?
testlibrary/ doesn't contain tests.
David
-----
> The updated webrev:
> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
>
> Thanks,
> Dima
>
> On 10.06.2014 7:39, David Holmes wrote:
>> Thanks Dima this looks okay to me.
>>
>> David
>>
>> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>>> Hi David,
>>>
>>> This is the updated version:
>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>>
>>> I ran all applicable_* groups with the corresponding GC. No failures
>>> caused by conflicts.
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 06.06.2014 9:47, David Holmes wrote:
>>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>> The existing nomenclature uses needs_xxx not requires_xxx, please
>>>>> maintain consistency with what exists.
>>>>
>>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>>> comments I keep saying requires.
>>>>
>>>> David
>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>>> Hello,
>>>>>>
>>>>>> This fix introduces new jtreg groups to allow not running tests which
>>>>>> could conflict because of GC.
>>>>>> Please note, this solution is temporary for 2-3 months, unless jtreg
>>>>>> starts support the @requires tag
>>>>>> (CODETOOLS-7900307)
>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>>
>>>>>> The change itself doesn't affect anything, it just allows to run
>>>>>> group
>>>>>> of tests which doesn't require a specific gc.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>>
>>>>>> Testing:
>>>>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC and
>>>>>> saw
>>>>>> only known issues not related to the conflict of flags.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>
>
From dmitry.fazunenko at oracle.com Wed Jun 11 09:25:17 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 11 Jun 2014 13:25:17 +0400
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <53981BED.4030907@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
<53973A73.8080507@oracle.com> <53981BED.4030907@oracle.com>
Message-ID: <5398207D.6000506@oracle.com>
On 11.06.2014 13:05, David Holmes wrote:
> On 11/06/2014 3:03 AM, Dmitry Fazunenko wrote:
>> Hi David,
>>
>> thanks for the prompt review.
>> Would you mind if the "all_hs_tests" group includes "testlibrary/" and
>> "testlibrary_tests/"?
>
> testlibrary/ doesn't contain tests.
I thought the same, but there there are 4 ctw tests there... Perhaps,
they should be relocated, but it's a different story.
Thanks,
Dima
>
> David
> -----
>
>> The updated webrev:
>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
>>
>> Thanks,
>> Dima
>>
>> On 10.06.2014 7:39, David Holmes wrote:
>>> Thanks Dima this looks okay to me.
>>>
>>> David
>>>
>>> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>>>> Hi David,
>>>>
>>>> This is the updated version:
>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>>>
>>>> I ran all applicable_* groups with the corresponding GC. No failures
>>>> caused by conflicts.
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 06.06.2014 9:47, David Holmes wrote:
>>>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>>>> Hi Dmitry,
>>>>>>
>>>>>> The existing nomenclature uses needs_xxx not requires_xxx, please
>>>>>> maintain consistency with what exists.
>>>>>
>>>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>>>> comments I keep saying requires.
>>>>>
>>>>> David
>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> This fix introduces new jtreg groups to allow not running tests
>>>>>>> which
>>>>>>> could conflict because of GC.
>>>>>>> Please note, this solution is temporary for 2-3 months, unless
>>>>>>> jtreg
>>>>>>> starts support the @requires tag
>>>>>>> (CODETOOLS-7900307)
>>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>>>
>>>>>>> The change itself doesn't affect anything, it just allows to run
>>>>>>> group
>>>>>>> of tests which doesn't require a specific gc.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>>>
>>>>>>> Testing:
>>>>>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC
>>>>>>> and
>>>>>>> saw
>>>>>>> only known issues not related to the conflict of flags.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>
>>
From david.holmes at oracle.com Wed Jun 11 09:40:55 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jun 2014 19:40:55 +1000
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <5397DC80.3020908@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com> <539683D4.9030508@oracle.com>
<539684FF.4070205@oracle.com> <53968D87.5010001@oracle.com>
<5396AFD7.8090900@oracle.com> <5396FEDB.8040509@oracle.com>
<5397DC80.3020908@oracle.com>
Message-ID: <53982427.2060109@oracle.com>
On 11/06/2014 2:35 PM, Daniel D. Daugherty wrote:
> On 6/10/14 6:49 AM, Daniel D. Daugherty wrote:
>> David,
>>
>> Thanks for the fast code review!
>>
>>
>> On 6/10/14 1:12 AM, David Holmes wrote:
>>> On 10/06/2014 2:45 PM, serguei.spitsyn at oracle.com wrote:
>>>> It looks good to me.
>>>> It is still hard to guarantee there are no other unexpected thread
>>>> states,
>>>
>>> I also wonder about that.
>>>
>>> But I also question whether this is even possible:
>>>
>>> 253 // Example 2: (This example has not yet been spotted)
>>> 254 // "ContendingThread-1" #23 prio=5 os_prio=64
>>> tid=0x0000000001556000 nid=0x30 waiting on condition
>>> [0xfffffd7fbf17e000]
>>> 255 // java.lang.Thread.State: BLOCKED (on object monitor)
>>>
>>> I don't see how you can be blocking on an object monitor but suddenly
>>> appear to be waiting on a condition ??
>>
>> That would be why I said "This example has not yet been spotted".
>> Yes, I'm being paranoid, but you knew that anyway :-)
>>
>>
>>> Looking at the comments in the bug, the Threads_lock is a mutex so it
>>> uses ParkEvent::park, which is PlatformEvent::park which doesn't use
>>> OSThreadWaitState.
>>
>> I'll chase this down with a native stack trace to see where
>> we are exactly. I don't know if I'll be able to get that done
>> today...
>
> So I chased this down to the VM_Deopt call that results from
> the -XX:+DeoptimizeALot option. So yes, my original comment
> about Parker::park() is wrong, but the bug now has the gory
> details of how we really got there...
Yep - nasty stuff :)
Thanks,
David
> Dan
>
>
>>
>> Dan
>>
>>
>>>
>>> David
>>> -----
>>>
>>>
>>>> but running for 3600 samples with no fails is convincing.
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 6/9/14 9:09 PM, Daniel D. Daugherty wrote:
>>>>> I forgot to include a handy link to the bug:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>>>>
>>>>> Also, the new test was run for 3600 samples with the
>>>>> -Xcomp and -XX:+DeoptimizeALot options which takes
>>>>> about 45 minutes. With those options, the bad test
>>>>> would fail in < 15 samples.
>>>>>
>>>>> The new test was also run for 3600 samples in the
>>>>> default config which takes about 42 minutes and did
>>>>> not fail in that config.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> Nightly testing has revealed a bug in the test that reproduces
>>>>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>>>>
>>>>>> Here's the webrev URL for the minor tweak to catch yet more
>>>>>> variation of the waiting pattern:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>>>>
>>>>>> Thanks to Vladimir K for reporting the test failure and for
>>>>>> providing the right details in the bug report.
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>>>>> One more round of review after refactoring the test based on
>>>>>>> comments
>>>>>>> from David H and Serguei.
>>>>>>>
>>>>>>> Here's the webrev for this round:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>>>>
>>>>>>> Had to change the default sample size from 30 -> 15 in order to
>>>>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>>>>
>>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>>>>
>>>>>>>> Here's the webrev URL for the next round:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>>>>
>>>>>>>> The fix has been tested with vm.quick on all Aurora Adhoc
>>>>>>>> platforms.
>>>>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>>>>> it is possible to get 30 runs in a row without failing.
>>>>>>>>
>>>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>>>>> This is a simple fix for incorrect lock state.
>>>>>>>>>
>>>>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>>>>>> check the monitor's owner, if the owner is other than the current
>>>>>>>>> thread, then the monitor, is or is in process of being, set the
>>>>>>>>> pending monitor of current thread.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>>
>>
>
From david.holmes at oracle.com Wed Jun 11 09:47:57 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jun 2014 19:47:57 +1000
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <5398207D.6000506@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
<53973A73.8080507@oracle.com> <53981BED.4030907@oracle.com>
<5398207D.6000506@oracle.com>
Message-ID: <539825CD.3090606@oracle.com>
On 11/06/2014 7:25 PM, Dmitry Fazunenko wrote:
>
> On 11.06.2014 13:05, David Holmes wrote:
>> On 11/06/2014 3:03 AM, Dmitry Fazunenko wrote:
>>> Hi David,
>>>
>>> thanks for the prompt review.
>>> Would you mind if the "all_hs_tests" group includes "testlibrary/" and
>>> "testlibrary_tests/"?
>>
>> testlibrary/ doesn't contain tests.
>
> I thought the same, but there there are 4 ctw tests there... Perhaps,
> they should be relocated, but it's a different story.
Ugghh! :( Yes they should be relocated. And yes that is a different story :)
Thanks,
David
> Thanks,
> Dima
>
>
>>
>> David
>> -----
>>
>>> The updated webrev:
>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 10.06.2014 7:39, David Holmes wrote:
>>>> Thanks Dima this looks okay to me.
>>>>
>>>> David
>>>>
>>>> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>>>>> Hi David,
>>>>>
>>>>> This is the updated version:
>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>>>>
>>>>> I ran all applicable_* groups with the corresponding GC. No failures
>>>>> caused by conflicts.
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>> On 06.06.2014 9:47, David Holmes wrote:
>>>>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>>>>> Hi Dmitry,
>>>>>>>
>>>>>>> The existing nomenclature uses needs_xxx not requires_xxx, please
>>>>>>> maintain consistency with what exists.
>>>>>>
>>>>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>>>>> comments I keep saying requires.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> This fix introduces new jtreg groups to allow not running tests
>>>>>>>> which
>>>>>>>> could conflict because of GC.
>>>>>>>> Please note, this solution is temporary for 2-3 months, unless
>>>>>>>> jtreg
>>>>>>>> starts support the @requires tag
>>>>>>>> (CODETOOLS-7900307)
>>>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>>>>
>>>>>>>> The change itself doesn't affect anything, it just allows to run
>>>>>>>> group
>>>>>>>> of tests which doesn't require a specific gc.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC
>>>>>>>> and
>>>>>>>> saw
>>>>>>>> only known issues not related to the conflict of flags.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dima
>>>>>
>>>
>
From igor.ignatyev at oracle.com Wed Jun 11 10:06:16 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 11 Jun 2014 14:06:16 +0400
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <539825CD.3090606@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
<53973A73.8080507@oracle.com> <53981BED.4030907@oracle.com>
<5398207D.6000506@oracle.com> <539825CD.3090606@oracle.com>
Message-ID: <53982A18.3080704@oracle.com>
Dima,
we already have the group which contains all tests -- 'jdk'. is it
possible to use it instead of 'all_hs_tests'?
Igor
On 06/11/2014 01:47 PM, David Holmes wrote:
> On 11/06/2014 7:25 PM, Dmitry Fazunenko wrote:
>>
>> On 11.06.2014 13:05, David Holmes wrote:
>>> On 11/06/2014 3:03 AM, Dmitry Fazunenko wrote:
>>>> Hi David,
>>>>
>>>> thanks for the prompt review.
>>>> Would you mind if the "all_hs_tests" group includes "testlibrary/" and
>>>> "testlibrary_tests/"?
>>>
>>> testlibrary/ doesn't contain tests.
>>
>> I thought the same, but there there are 4 ctw tests there... Perhaps,
>> they should be relocated, but it's a different story.
>
> Ugghh! :( Yes they should be relocated. And yes that is a different
> story :)
>
> Thanks,
> David
>
>> Thanks,
>> Dima
>>
>>
>>>
>>> David
>>> -----
>>>
>>>> The updated webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 10.06.2014 7:39, David Holmes wrote:
>>>>> Thanks Dima this looks okay to me.
>>>>>
>>>>> David
>>>>>
>>>>> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> This is the updated version:
>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>>>>>
>>>>>> I ran all applicable_* groups with the corresponding GC. No failures
>>>>>> caused by conflicts.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> On 06.06.2014 9:47, David Holmes wrote:
>>>>>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>>>>>> Hi Dmitry,
>>>>>>>>
>>>>>>>> The existing nomenclature uses needs_xxx not requires_xxx, please
>>>>>>>> maintain consistency with what exists.
>>>>>>>
>>>>>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>>>>>> comments I keep saying requires.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> This fix introduces new jtreg groups to allow not running tests
>>>>>>>>> which
>>>>>>>>> could conflict because of GC.
>>>>>>>>> Please note, this solution is temporary for 2-3 months, unless
>>>>>>>>> jtreg
>>>>>>>>> starts support the @requires tag
>>>>>>>>> (CODETOOLS-7900307)
>>>>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>>>>>
>>>>>>>>> The change itself doesn't affect anything, it just allows to run
>>>>>>>>> group
>>>>>>>>> of tests which doesn't require a specific gc.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC
>>>>>>>>> and
>>>>>>>>> saw
>>>>>>>>> only known issues not related to the conflict of flags.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dima
>>>>>>
>>>>
>>
From david.holmes at oracle.com Wed Jun 11 10:23:07 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jun 2014 20:23:07 +1000
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <53982A18.3080704@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
<53973A73.8080507@oracle.com> <53981BED.4030907@oracle.com>
<5398207D.6000506@oracle.com> <539825CD.3090606@oracle.com>
<53982A18.3080704@oracle.com>
Message-ID: <53982E0B.5020107@oracle.com>
On 11/06/2014 8:06 PM, Igor Ignatyev wrote:
> Dima,
>
> we already have the group which contains all tests -- 'jdk'. is it
> possible to use it instead of 'all_hs_tests'?
Yes that is true - I'd lost sight of that. In particular I hadn't
realized the testlibrary and testlibrary_tests were already in the
compact1 group.
Group jdk is all tests, so no need for all_hs_tests.
David
> Igor
>
> On 06/11/2014 01:47 PM, David Holmes wrote:
>> On 11/06/2014 7:25 PM, Dmitry Fazunenko wrote:
>>>
>>> On 11.06.2014 13:05, David Holmes wrote:
>>>> On 11/06/2014 3:03 AM, Dmitry Fazunenko wrote:
>>>>> Hi David,
>>>>>
>>>>> thanks for the prompt review.
>>>>> Would you mind if the "all_hs_tests" group includes "testlibrary/" and
>>>>> "testlibrary_tests/"?
>>>>
>>>> testlibrary/ doesn't contain tests.
>>>
>>> I thought the same, but there there are 4 ctw tests there... Perhaps,
>>> they should be relocated, but it's a different story.
>>
>> Ugghh! :( Yes they should be relocated. And yes that is a different
>> story :)
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> Dima
>>>
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>>> The updated webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>> On 10.06.2014 7:39, David Holmes wrote:
>>>>>> Thanks Dima this looks okay to me.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> This is the updated version:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>>>>>>
>>>>>>> I ran all applicable_* groups with the corresponding GC. No failures
>>>>>>> caused by conflicts.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>>>
>>>>>>> On 06.06.2014 9:47, David Holmes wrote:
>>>>>>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>>>>>>> Hi Dmitry,
>>>>>>>>>
>>>>>>>>> The existing nomenclature uses needs_xxx not requires_xxx, please
>>>>>>>>> maintain consistency with what exists.
>>>>>>>>
>>>>>>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>>>>>>> comments I keep saying requires.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> This fix introduces new jtreg groups to allow not running tests
>>>>>>>>>> which
>>>>>>>>>> could conflict because of GC.
>>>>>>>>>> Please note, this solution is temporary for 2-3 months, unless
>>>>>>>>>> jtreg
>>>>>>>>>> starts support the @requires tag
>>>>>>>>>> (CODETOOLS-7900307)
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>>>>>>
>>>>>>>>>> The change itself doesn't affect anything, it just allows to run
>>>>>>>>>> group
>>>>>>>>>> of tests which doesn't require a specific gc.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Testing:
>>>>>>>>>> I ran all 4 ":applicable_XXXgc" groups with the corresponding GC
>>>>>>>>>> and
>>>>>>>>>> saw
>>>>>>>>>> only known issues not related to the conflict of flags.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dima
>>>>>>>
>>>>>
>>>
From dmitry.fazunenko at oracle.com Wed Jun 11 10:36:22 2014
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 11 Jun 2014 14:36:22 +0400
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <53982E0B.5020107@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
<53973A73.8080507@oracle.com> <53981BED.4030907@oracle.com>
<5398207D.6000506@oracle.com> <539825CD.3090606@oracle.com>
<53982A18.3080704@oracle.com> <53982E0B.5020107@oracle.com>
Message-ID: <53983126.8030906@oracle.com>
jdk is defined in some exotic way:
jdk = \
:jre \
:needs_jdk
where
jre = \
:compact3 \
:needs_jre \
-:needs_jdk
needs_jdk = <list some tests>
I decided there must have been some reasons to define "jdk" not as
everything in "test/".
Looking at current definition of jdk is hard to say which tests are
included in that group...
Okay, I will execute the tests with "jdk" and check that the number is
the same.
I hope that the @requires tag will eliminate all that mess with the groups.
Thanks,
Dima
On 11.06.2014 14:23, David Holmes wrote:
> On 11/06/2014 8:06 PM, Igor Ignatyev wrote:
>> Dima,
>>
>> we already have the group which contains all tests -- 'jdk'. is it
>> possible to use it instead of 'all_hs_tests'?
>
> Yes that is true - I'd lost sight of that. In particular I hadn't
> realized the testlibrary and testlibrary_tests were already in the
> compact1 group.
>
> Group jdk is all tests, so no need for all_hs_tests.
>
> David
>
>> Igor
>>
>> On 06/11/2014 01:47 PM, David Holmes wrote:
>>> On 11/06/2014 7:25 PM, Dmitry Fazunenko wrote:
>>>>
>>>> On 11.06.2014 13:05, David Holmes wrote:
>>>>> On 11/06/2014 3:03 AM, Dmitry Fazunenko wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> thanks for the prompt review.
>>>>>> Would you mind if the "all_hs_tests" group includes
>>>>>> "testlibrary/" and
>>>>>> "testlibrary_tests/"?
>>>>>
>>>>> testlibrary/ doesn't contain tests.
>>>>
>>>> I thought the same, but there there are 4 ctw tests there... Perhaps,
>>>> they should be relocated, but it's a different story.
>>>
>>> Ugghh! :( Yes they should be relocated. And yes that is a different
>>> story :)
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>>
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> The updated webrev:
>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> On 10.06.2014 7:39, David Holmes wrote:
>>>>>>> Thanks Dima this looks okay to me.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> This is the updated version:
>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>>>>>>>
>>>>>>>>
>>>>>>>> I ran all applicable_* groups with the corresponding GC. No
>>>>>>>> failures
>>>>>>>> caused by conflicts.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dima
>>>>>>>>
>>>>>>>> On 06.06.2014 9:47, David Holmes wrote:
>>>>>>>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>
>>>>>>>>>> The existing nomenclature uses needs_xxx not requires_xxx,
>>>>>>>>>> please
>>>>>>>>>> maintain consistency with what exists.
>>>>>>>>>
>>>>>>>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>>>>>>>> comments I keep saying requires.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> This fix introduces new jtreg groups to allow not running tests
>>>>>>>>>>> which
>>>>>>>>>>> could conflict because of GC.
>>>>>>>>>>> Please note, this solution is temporary for 2-3 months, unless
>>>>>>>>>>> jtreg
>>>>>>>>>>> starts support the @requires tag
>>>>>>>>>>> (CODETOOLS-7900307)
>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>>>>>>>
>>>>>>>>>>> The change itself doesn't affect anything, it just allows to
>>>>>>>>>>> run
>>>>>>>>>>> group
>>>>>>>>>>> of tests which doesn't require a specific gc.
>>>>>>>>>>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>>>>>>>> Webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Testing:
>>>>>>>>>>> I ran all 4 ":applicable_XXXgc" groups with the
>>>>>>>>>>> corresponding GC
>>>>>>>>>>> and
>>>>>>>>>>> saw
>>>>>>>>>>> only known issues not related to the conflict of flags.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dima
>>>>>>>>
>>>>>>
>>>>
From david.holmes at oracle.com Wed Jun 11 12:23:08 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jun 2014 22:23:08 +1000
Subject: RFR(s): 8044673: Create jtreg groups to list GC specific tests
In-Reply-To: <53983126.8030906@oracle.com>
References: <537E1EC3.9080607@oracle.com> <538F453E.6010105@oracle.com>
<53915403.4030005@oracle.com> <539155E2.2050901@oracle.com>
<5395848D.2010704@oracle.com> <53967DD6.50900@oracle.com>
<53973A73.8080507@oracle.com> <53981BED.4030907@oracle.com>
<5398207D.6000506@oracle.com> <539825CD.3090606@oracle.com>
<53982A18.3080704@oracle.com> <53982E0B.5020107@oracle.com>
<53983126.8030906@oracle.com>
Message-ID: <53984A2C.7080703@oracle.com>
On 11/06/2014 8:36 PM, Dmitry Fazunenko wrote:
> jdk is defined in some exotic way:
>
> jdk = \
> :jre \
> :needs_jdk
>
> where
> jre = \
> :compact3 \
> :needs_jre \
> -:needs_jdk
>
> needs_jdk = <list some tests>
>
> I decided there must have been some reasons to define "jdk" not as
> everything in "test/".
There was. I needed to define groups from the bottom up - starting with
compact1 and also accounting for the specific VM. But ultimately jdk
combines everything back together - it just does so in terms of the
subgroups underneath it.
> Looking at current definition of jdk is hard to say which tests are
> included in that group...
>
> Okay, I will execute the tests with "jdk" and check that the number is
> the same.
>
> I hope that the @requires tag will eliminate all that mess with the groups.
I doubt it. It will just present a differently arranged mess.
David
> Thanks,
> Dima
>
>
>
> On 11.06.2014 14:23, David Holmes wrote:
>> On 11/06/2014 8:06 PM, Igor Ignatyev wrote:
>>> Dima,
>>>
>>> we already have the group which contains all tests -- 'jdk'. is it
>>> possible to use it instead of 'all_hs_tests'?
>>
>> Yes that is true - I'd lost sight of that. In particular I hadn't
>> realized the testlibrary and testlibrary_tests were already in the
>> compact1 group.
>>
>> Group jdk is all tests, so no need for all_hs_tests.
>>
>> David
>>
>>> Igor
>>>
>>> On 06/11/2014 01:47 PM, David Holmes wrote:
>>>> On 11/06/2014 7:25 PM, Dmitry Fazunenko wrote:
>>>>>
>>>>> On 11.06.2014 13:05, David Holmes wrote:
>>>>>> On 11/06/2014 3:03 AM, Dmitry Fazunenko wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> thanks for the prompt review.
>>>>>>> Would you mind if the "all_hs_tests" group includes
>>>>>>> "testlibrary/" and
>>>>>>> "testlibrary_tests/"?
>>>>>>
>>>>>> testlibrary/ doesn't contain tests.
>>>>>
>>>>> I thought the same, but there there are 4 ctw tests there... Perhaps,
>>>>> they should be relocated, but it's a different story.
>>>>
>>>> Ugghh! :( Yes they should be relocated. And yes that is a different
>>>> story :)
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>>
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> The updated webrev:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dima
>>>>>>>
>>>>>>> On 10.06.2014 7:39, David Holmes wrote:
>>>>>>>> Thanks Dima this looks okay to me.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 9/06/2014 7:55 PM, Dmitry Fazunenko wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> This is the updated version:
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.01/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I ran all applicable_* groups with the corresponding GC. No
>>>>>>>>> failures
>>>>>>>>> caused by conflicts.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dima
>>>>>>>>>
>>>>>>>>> On 06.06.2014 9:47, David Holmes wrote:
>>>>>>>>>> On 6/06/2014 3:39 PM, David Holmes wrote:
>>>>>>>>>>> Hi Dmitry,
>>>>>>>>>>>
>>>>>>>>>>> The existing nomenclature uses needs_xxx not requires_xxx,
>>>>>>>>>>> please
>>>>>>>>>>> maintain consistency with what exists.
>>>>>>>>>>
>>>>>>>>>> And yes I'm guilty of naming the groups needs_xxx while in the
>>>>>>>>>> comments I keep saying requires.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 5/06/2014 2:11 AM, Dmitry Fazunenko wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> This fix introduces new jtreg groups to allow not running tests
>>>>>>>>>>>> which
>>>>>>>>>>>> could conflict because of GC.
>>>>>>>>>>>> Please note, this solution is temporary for 2-3 months, unless
>>>>>>>>>>>> jtreg
>>>>>>>>>>>> starts support the @requires tag
>>>>>>>>>>>> (CODETOOLS-7900307)
>>>>>>>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7900307>
>>>>>>>>>>>>
>>>>>>>>>>>> The change itself doesn't affect anything, it just allows to
>>>>>>>>>>>> run
>>>>>>>>>>>> group
>>>>>>>>>>>> of tests which doesn't require a specific gc.
>>>>>>>>>>>>
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044673
>>>>>>>>>>>> Webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8044673/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Testing:
>>>>>>>>>>>> I ran all 4 ":applicable_XXXgc" groups with the
>>>>>>>>>>>> corresponding GC
>>>>>>>>>>>> and
>>>>>>>>>>>> saw
>>>>>>>>>>>> only known issues not related to the conflict of flags.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dima
>>>>>>>>>
>>>>>>>
>>>>>
>
From dan at danny.cz Wed Jun 11 15:12:23 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Wed, 11 Jun 2014 17:12:23 +0200
Subject: PATCH: swapped usage of idx_t and bm_word_t types in
parMarkBitMap.cpp
In-Reply-To: <1401095553.2642.4.camel@cirrus>
References: <20140522101904.a9a5d06f13b9b13cf64fca4e@danny.cz>
<1400750628.2617.11.camel@cirrus>
<20140522115947.5ce5ad198a35e8155a9c1f59@danny.cz>
<1401095553.2642.4.camel@cirrus>
Message-ID: <20140611171223.2083cc5a8e189eb22ff3afa4@danny.cz>
On Mon, 26 May 2014 11:12:33 +0200
Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> Hi,
>
> On Thu, 2014-05-22 at 11:59 +0200, Dan Hor?k wrote:
> > On Thu, 22 May 2014 11:23:48 +0200
> > Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> >
> > > Hi Dan,
> > >
> > > On Thu, 2014-05-22 at 10:19 +0200, Dan Hor?k wrote:
> > > > Hello,
> > > >
> [...]
> > > > This a follow-up of my earlier s390 related patch [2]
> > > >
> > > > [1] http://fedora.danny.cz/openjdk/bitmap-1/webrev/
> > > > [2]
> > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-September/010913.html
> > > >
> > > > Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
> > > > covered by Red Hat's CLA for my contributions.
> > > >
> > >
> > > Created https://bugs.openjdk.java.net/browse/JDK-8043722 .
> > >
> > > I roughly looked at other similar changes, shouldn't line 129 in
> > > g1/concurrentMark.cpp changed too?
> > >
> > > 129 _bm.set_map((uintptr_t*)_virtual_space.low());
> > >
> > > @Compiler team: what about the instantiations of
> > > MethodLivenessResult?
> > >
> > > I.e. in methodLiveness.cpp:476 and 1001 there are two other
> > > uintptr_t* casts.
> >
> > they don't fail the build because bm_word_t is uintptr_t, but in my
> > opinion they should be changed too, at least for consistency
>
> Can you check the patch at
> http://cr.openjdk.java.net/~tschatzl/8043722/webrev/ for S390? It
> builds on all Oracle platforms.
>
> If so, your change has been reviewed by me.
yes, your updated patch builds also on s390, sorry for the late answer
Thanks
Dan
From kim.barrett at oracle.com Wed Jun 11 15:31:18 2014
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Jun 2014 11:31:18 -0400
Subject: RFR(XS): 8046408: Build failure from multiple ptrace.h
Message-ID: <99ACD0C8-F578-4DD0-9CA6-243648690E96@oracle.com>
Please review the following 1-line change which is needed to avoid
build failures on some platforms.
webrev: http://cr.openjdk.java.net/~mikael/webrevs/kim-8046408/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8046408
There are two ptrace.h headers available for linux, <sys/ptrace.h> and
<linux/ptrace.h>. A new struct (ptrace_peeksiginfo_args) was recently
added to each, but the addition in <sys/ptrace.h> didn't follow the
convention there of using a double-underscore prefix for type names
declared in that file. As a result, if both headers are included (as
is occurring in our code), there are multiple definitions of that
struct. It appears to be a "well known" problem that already has a
fix [1], but glibc 2.18 was released with this problem.
The inclusion of both variants was due to a file (ps_proc.c) directly
including sys/ptrace and indirectly including linux/ptrace, where the
indirectly including header is used in other places that don't include
sys/ptrace. Our code can presently use either of the headers; I'm
proposing we prefer sys/ptrace rather than linux/ptrace. A different
1-line change would be to remove the direct include of sys/ptrace and
let that file rely on the indirect include of linux/ptrace, but I
dislike that, since ps_proc.c directly uses lots of names defined in
those headers.
[1] https://www.sourceware.org/ml/libc-alpha/2014-01/msg00078.html
From vladimir.kozlov at oracle.com Wed Jun 11 16:52:03 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 11 Jun 2014 09:52:03 -0700
Subject: [8u20] (S) 8046275: Fastdebug build failing on jdk9/hs/ control jobs
after pulling some hs-comp changes
Message-ID: <53988933.9070600@oracle.com>
8u20 backport request. The fix was pushed into jdk9 2 days ago and nightly testing shows no problems.
Changes from jdk9 applied to 8u without conflicts.
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3cb509208318
http://cr.openjdk.java.net/~kvn/8046275/webrev
https://bugs.openjdk.java.net/browse/JDK-8046275
Thanks,
Vladimir
From staffan.larsen at oracle.com Wed Jun 11 18:22:19 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 11 Jun 2014 20:22:19 +0200
Subject: RFR(XS): 8046408: Build failure from multiple ptrace.h
In-Reply-To: <99ACD0C8-F578-4DD0-9CA6-243648690E96@oracle.com>
References: <99ACD0C8-F578-4DD0-9CA6-243648690E96@oracle.com>
Message-ID: <DAF70D5C-32BF-4B32-942E-9867D9C4594A@oracle.com>
Looks good!
Thanks,
/Staffan
On 11 jun 2014, at 17:31, Kim Barrett <kim.barrett at oracle.com> wrote:
> Please review the following 1-line change which is needed to avoid
> build failures on some platforms.
>
> webrev: http://cr.openjdk.java.net/~mikael/webrevs/kim-8046408/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8046408
>
> There are two ptrace.h headers available for linux, <sys/ptrace.h> and
> <linux/ptrace.h>. A new struct (ptrace_peeksiginfo_args) was recently
> added to each, but the addition in <sys/ptrace.h> didn't follow the
> convention there of using a double-underscore prefix for type names
> declared in that file. As a result, if both headers are included (as
> is occurring in our code), there are multiple definitions of that
> struct. It appears to be a "well known" problem that already has a
> fix [1], but glibc 2.18 was released with this problem.
>
> The inclusion of both variants was due to a file (ps_proc.c) directly
> including sys/ptrace and indirectly including linux/ptrace, where the
> indirectly including header is used in other places that don't include
> sys/ptrace. Our code can presently use either of the headers; I'm
> proposing we prefer sys/ptrace rather than linux/ptrace. A different
> 1-line change would be to remove the direct include of sys/ptrace and
> let that file rely on the indirect include of linux/ptrace, but I
> dislike that, since ps_proc.c directly uses lots of names defined in
> those headers.
>
> [1] https://www.sourceware.org/ml/libc-alpha/2014-01/msg00078.html
>
From mikael.vidstedt at oracle.com Wed Jun 11 18:25:41 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 11 Jun 2014 11:25:41 -0700
Subject: RFR(XS): 8046408: Build failure from multiple ptrace.h
In-Reply-To: <DAF70D5C-32BF-4B32-942E-9867D9C4594A@oracle.com>
References: <99ACD0C8-F578-4DD0-9CA6-243648690E96@oracle.com>
<DAF70D5C-32BF-4B32-942E-9867D9C4594A@oracle.com>
Message-ID: <53989F25.9060102@oracle.com>
Looks good, thanks for cleaning up after me! :)
Cheers,
Mikael
On 2014-06-11 11:22, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
> On 11 jun 2014, at 17:31, Kim Barrett <kim.barrett at oracle.com> wrote:
>
>> Please review the following 1-line change which is needed to avoid
>> build failures on some platforms.
>>
>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/kim-8046408/webrev/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8046408
>>
>> There are two ptrace.h headers available for linux, <sys/ptrace.h> and
>> <linux/ptrace.h>. A new struct (ptrace_peeksiginfo_args) was recently
>> added to each, but the addition in <sys/ptrace.h> didn't follow the
>> convention there of using a double-underscore prefix for type names
>> declared in that file. As a result, if both headers are included (as
>> is occurring in our code), there are multiple definitions of that
>> struct. It appears to be a "well known" problem that already has a
>> fix [1], but glibc 2.18 was released with this problem.
>>
>> The inclusion of both variants was due to a file (ps_proc.c) directly
>> including sys/ptrace and indirectly including linux/ptrace, where the
>> indirectly including header is used in other places that don't include
>> sys/ptrace. Our code can presently use either of the headers; I'm
>> proposing we prefer sys/ptrace rather than linux/ptrace. A different
>> 1-line change would be to remove the direct include of sys/ptrace and
>> let that file rely on the indirect include of linux/ptrace, but I
>> dislike that, since ps_proc.c directly uses lots of names defined in
>> those headers.
>>
>> [1] https://www.sourceware.org/ml/libc-alpha/2014-01/msg00078.html
>>
From david.dehaven at oracle.com Wed Jun 11 20:06:22 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 11 Jun 2014 13:06:22 -0700
Subject: Fwd: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
Message-ID: <173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
Can I get hotspot signoff on the (fairly trivial) hotspot changes for this?
The hotspot specific changes are here:
http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/
Also, is there a problem if I push these through jdk9/build instead of going through hotspot?
I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results.
-DrD-
> From: David DeHaven <david.dehaven at oracle.com>
> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
> Date: June 4, 2014 16:01:29 PDT
> To: build-dev build-dev <build-dev at openjdk.java.net>
>
>
> Next (hopefully last??) update:
> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>
> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>
> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>
>
> These comments in flags.m4 are a bit misleading and not really true:
> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
> # FIXME: clean this up, and/or move it elsewhere.
>
> So, I removed them...
>
> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>
>
>
> Testing:
>
> I now have two system configurations I'm testing with:
> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>
> System 1 tests:
> $ sudo xcode-select -switch /Applications/Xcode.app
> $ make clean; sh ./configure; make images
> ...
> 00:09:17 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
>
> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
> ...
> 00:13:37 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
> (Note that building with Xcode 5/clang is faster...)
>
>
> $ sudo xcode-select -switch /Applications/old/Xcode4.app
> $ make clean; sh ./configure; make images
> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>
>
> $ make clean; sh ./configure --with-toolchain-type=clang; make images
> ...
> 00:10:54 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
>
> System 2 tests:
> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
> ...
> 00:20:26 TOTAL
> -------------------------
> Finished building OpenJDK for target 'images'
>
>
> Closed JDK (images only, deploy/install expected to fail)
> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
> ...
> 00:10:05 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
> -DrD-
>
From coleen.phillimore at oracle.com Wed Jun 11 21:13:37 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 11 Jun 2014 17:13:37 -0400
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
Message-ID: <5398C681.70209@oracle.com>
Summary: Write klass and resolved_references constant pool fields lock free.
The constant pool values that can change were already read lock free,
through the cpSlot type (lsb set for Symbol vs. Klass) for
JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other
values that can change were moved to the resolved_references array,
which is initialized to null. Non-null is the resolved value. With a
couple uses of CAS, we can eliminate the need for the constant pool lock
for the constant pool changes. Error handling also changes the tag but
saving the resolution exception was done under the
SystemDictionary_lock, so only the tag change needs a CAS.
The only remaining use for the constant pool lock is updating the
cpCache for invokedynamic. There are 4 fields that need to be
consistent. These now use the metaspace lock associated with the class
loader that owns the constant pool, which is only held briefly. I ran
some performance tests written by Sergey Kuksenko which show no regression.
Other testing - ran refworkload on linux x64 with no significant
results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests, hotspot
jtreg tests and jdk java/lang/invoke jtreg tests.
open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
bug link https://bugs.openjdk.java.net/browse/JDK-8026977
Thanks,
Coleen
From igor.veresov at oracle.com Wed Jun 11 22:33:05 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 11 Jun 2014 15:33:05 -0700
Subject: [8u20] (S) 8046275: Fastdebug build failing on jdk9/hs/ control
jobs after pulling some hs-comp changes
In-Reply-To: <53988933.9070600@oracle.com>
References: <53988933.9070600@oracle.com>
Message-ID: <12D2AF9D-EA89-45D8-B87B-DD1F5B201B57@oracle.com>
Good.
igor
On Jun 11, 2014, at 9:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 8u20 backport request. The fix was pushed into jdk9 2 days ago and nightly testing shows no problems.
>
> Changes from jdk9 applied to 8u without conflicts.
>
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3cb509208318
> http://cr.openjdk.java.net/~kvn/8046275/webrev
> https://bugs.openjdk.java.net/browse/JDK-8046275
>
> Thanks,
> Vladimir
From daniel.daugherty at oracle.com Wed Jun 11 22:36:25 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 11 Jun 2014 16:36:25 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <539683D4.9030508@oracle.com>
References: <537A0E1C.4070605@oracle.com> <537ECC1A.1030409@oracle.com>
<53874908.5070805@oracle.com> <539683D4.9030508@oracle.com>
Message-ID: <5398D9E9.6010608@oracle.com>
Greetings,
Let's try this hopefully one last time:
http://cr.openjdk.java.net/~dcubed/8046287-webrev/1-jdk9-hs-rt/
https://bugs.openjdk.java.net/browse/JDK-8046287
Changes relative to the ORIGINAL version of the test:
- added a new header waiting pattern to catch the case where
the target thread waiting on a condition (like a VM op)
- add synchronization to the start-up of the contending threads
so that we don't start sampling while the contending threads
are initializing
- add sanity check for observing only two "ContendingThread-*"
stack traces
- rename some variables to make their use more clear
- update/add various comments
- add counters for the various checks and report a summary
of all the sampling runs
- issue a warning if the specific scenario encountered by
the original bug (8036823) is never seen
Testing:
- JPRT test run of the test using product and fastdebug
bits on all the usual platforms
- 3600 sample run with fastdebug bits:
INFO: Summary for all samples:
INFO: both_running_cnt=0
INFO: both_waiting_cnt=0
INFO: contended_cnt=2005
INFO: one_waiting_cnt=1405
INFO: uncontended_cnt=190
- 3600 sample run with fastdebug bits w/ -Xcomp:
INFO: Summary for all samples:
INFO: both_running_cnt=0
INFO: both_waiting_cnt=0
INFO: contended_cnt=1867
INFO: one_waiting_cnt=1548
INFO: uncontended_cnt=185
- 3600 sample run with fastdebug bits w/ -Xcomp -XX:+DeoptimizeALot:
INFO: Summary for all samples:
INFO: both_running_cnt=46
INFO: both_waiting_cnt=0
INFO: contended_cnt=3135
INFO: one_waiting_cnt=3
INFO: uncontended_cnt=416
The contended_cnt is where we're hitting the original
bug's scenario and we've got great coverage there.
The other counts reflect how often we hit the edge
cases...
Thanks, in advance, for any comments, questions or suggestions.
Dan
On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> Nightly testing has revealed a bug in the test that reproduces
> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>
> Here's the webrev URL for the minor tweak to catch yet more
> variation of the waiting pattern:
>
> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>
> Thanks to Vladimir K for reporting the test failure and for
> providing the right details in the bug report.
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>
>
> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>> One more round of review after refactoring the test based on comments
>> from David H and Serguei.
>>
>> Here's the webrev for this round:
>>
>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>
>> Had to change the default sample size from 30 -> 15 in order to
>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>
>>> Here's the webrev URL for the next round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>
>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>> The new test has been run with the fix via JPRT and passes on all
>>> JPRT platforms. The new test has also been run without the fix and
>>> fails on most platforms. Since the default sample size is just 30,
>>> it is possible to get 30 runs in a row without failing.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>> This is a simple fix for incorrect lock state.
>>>>
>>>> The timing on setting thread's pending monitor can result stack
>>>> trace dump reporting incorrect lock state. The solution is to check
>>>> the monitor's owner, if the owner is other than the current thread,
>>>> then the monitor, is or is in process of being, set the pending
>>>> monitor of current thread.
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>
>>>
>>>
>>
>>
>
>
From vladimir.kozlov at oracle.com Wed Jun 11 22:39:13 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 11 Jun 2014 15:39:13 -0700
Subject: [8u20] (S) 8046275: Fastdebug build failing on jdk9/hs/ control
jobs after pulling some hs-comp changes
In-Reply-To: <12D2AF9D-EA89-45D8-B87B-DD1F5B201B57@oracle.com>
References: <53988933.9070600@oracle.com>
<12D2AF9D-EA89-45D8-B87B-DD1F5B201B57@oracle.com>
Message-ID: <5398DA91.3080508@oracle.com>
Thank you, Igor
Vladimir
On 6/11/14 3:33 PM, Igor Veresov wrote:
> Good.
>
> igor
>
> On Jun 11, 2014, at 9:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> 8u20 backport request. The fix was pushed into jdk9 2 days ago and nightly testing shows no problems.
>>
>> Changes from jdk9 applied to 8u without conflicts.
>>
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3cb509208318
>> http://cr.openjdk.java.net/~kvn/8046275/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8046275
>>
>> Thanks,
>> Vladimir
>
From coleen.phillimore at oracle.com Wed Jun 11 23:21:50 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 11 Jun 2014 19:21:50 -0400
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
In-Reply-To: <537E4DB2.5020602@oracle.com>
References: <537E4DB2.5020602@oracle.com>
Message-ID: <5398E48E.9020201@oracle.com>
Hi Zhengyu,
I have early feedback but I haven't looked at the new files yet. Nothing
major. I like the new code and I'm glad you could add NMT tracking to
vmError reporting.
http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/solaris/vm/os_solaris.cpp.udiff.html
+ bool os::unsetenv(const char* name) {
+ assert(name != NULL, "Null pointer");
+ return (::unsetenv(name) == 0);
+ }
+
Can you add this to os_posix.cpp instead? Someday this duplicate code
will be consolidated so it can start in posix even though it's not posix.
http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/windows/vm/os_windows.cpp.udiff.html
I thought the original comment was more descriptive. Is it still a
workaround?
http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/share/vm/runtime/arguments.cpp.html
Can you factor lines 3596-3623 into a function like verify_nmt_flag? Is
it that you already know what nmt level is used from the launcher and
are just checking consistency and initializing here? These cascading
if() code checking options gets too long if you're not careful.
In memReporter.hpp
A short comment before each class what they are for and how you would
get to this code would be nice. I think they correspond to NMT settings
(summary vs. detail). Mem*DiffReporter reports the difference between
the current memory tracked and a previous snapshot it appears.
In memReporter.cpp
Lines 302-311, you could have two functions that does this same
calculation for these values so that it doesn't get broken. The same
calculation appears 61 and 64.
If you use size_t can you avoid eagerly scaling the amounts?
amount_in_current_scale appears 66 times which is a lot. Can you only
call the scaling when you print the amounts?
In MemTracker.hpp
Line 109, I think you can assert that the JVM is single threaded.
That's as far as I got today. This looks good!
Coleen
On 5/22/14, 3:19 PM, Zhengyu Gu wrote:
> This is significant rework of native memory tracking introduced in
> earlier releases.
>
> The goal of this enhancement is to improve scalability, from both
> tracking memory and CPU usage perspectives, so it can scale well with
> increased memory allocation in large applications.
>
> The enhancement is mainly focused on malloc memory tracking, whose
> activities are several magnitude higher than virtual memory, and was
> the main bottleneck in early implementation.
>
> Instead of using book keeping records for tracking malloc activities,
> new implementation co-locates tracking data along side with user data
> by using a prefixed header. The header size is 8 bytes on 32-bit
> systems and 16 bytes on 64-bit systems, which ensure that user data
> also align properly.
>
> Virtual memory tracking still uses book keeping records, and
> ThreadCritical lock is always acquired to alter the records and
> related data structures.
>
> Summary tracking data is maintained in static data structures, via
> atomic operations. Malloc detail tracking call stacks are maintained
> in a lock free hashtable.
>
> The key improvements:
> 1. Up-to-date tracking report.
> 2. Detail tracking now shows multiple call frames. Number of frames
> is compilation time decision, currently default to 4.
> 3. Malloc tracking is lock free.
> 4. Tracking summary is reported in hs_err file when native memory
> tracking is enabled.
> 5. Query is faster, uses little memory and need a very little process.
>
> The drawback is that, malloc tracking header is always needed if
> native memory tracking has ever been enabled, even after tracking is
> shutdown.
>
> Impacts:
> The most noticeable impact for JVM developers, is that Arena now
> also take memory type as constructor parameter, besides the new
> operators.
> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode)
> Arena(mtCode)
>
> The webrev shows modification of about 60 files, but most of them are
> due to tracking API changes, mainly due to tracking stack, now, is an
> object, vs. a single pc.
>
> The most important files for this implementations are:
>
> memTracker.hpp/cpp
> mallocTracker.hpp/cpp and mallocTracker.inline.hpp
> virtualMemoryTracker.hpp/cpp
> mallocSiteTable.hpp/cpp
>
> allocationSite.hpp
> nativeCallStack.hpp/cpp
> linkedlist.hpp
>
>
> Tests:
> - JPRT
> - NMT test suite
> - vm.quick.testlist
> - Kitchensink stability test for 16+ days
> - FMW
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8028541
> Webrev: http://cr.openjdk.java.net/~zgu/8028541/webrev.00/
>
> Thanks,
>
> -Zhengyu
>
From david.dehaven at oracle.com Wed Jun 11 23:24:11 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 11 Jun 2014 16:24:11 -0700
Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
In-Reply-To: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <D44CAE2D-47F8-4928-8BBB-A42F8F31DC9C@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <B0922C07-B80D-4E41-87FC-FD418848C4E4@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <CC96E1EC-AD10-41FE-BF63-AD90AEEC4745@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <E4CD3FDA-21AF-4289-9D13-249BE5CD3DC7@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com>
<27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com>
<538C3F03.7020207@oracle.com>
<B4394FA7-E2B5-4C7C-95EA-CA09F3AE4250@oracle.com>
<538D87EC.7080204@oracle.com> <AA8B151C-4889-45!
! ! 7E-B8F2-BDA2534ACF94@oracle.com>
<0120A774-30C6-49A9-81E7-CB14FF646F61@oracle.com>
<58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
Message-ID: <75BA6A2F-9D22-4FB5-8FF1-6E936FC0B156@oracle.com>
And just FYI, I got a mostly clean JPRT run:
Four failures, a couple already tracked by the following issues:
https://bugs.openjdk.java.net/browse/INTJDK-7609054
https://bugs.openjdk.java.net/browse/JDK-8043951 (reported to jprt_admin)
This might be related to the latter as it happened only on the same Solaris 10 systems:
TEST: sun/security/tools/keytool/default_options.sh
JDK under test: (/tmp/jprt/P1/201308.ddehaven/testproduct/solaris_sparcv9_5.10-product)
java version "1.9.0-internal"
Java(TM) SE Runtime Environment (build 1.9.0-internal-201406112013.ddehaven.jdk9-dev-b00)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-201406112013.ddehaven.jdk9-dev-b00, mixed mode)
ACTION: shell -- Failed. Execution failed: exit code 1
REASON: Assumed action based on file name: run shell default_options.sh
TIME: 0.012 seconds
messages:
command: shell default_options.sh
reason: Assumed action based on file name: run shell default_options.sh
elapsed time (seconds): 0.012
STDOUT:
STDERR:
/tmp/jprt/P1/201308.ddehaven/s/jdk/test/sun/security/tools/keytool/default_options.sh: PASS=changeit: is not an identifier
The last failure was due to an assertion failure in the test report generator (???), the tests themselves passed so I'm not concerned about it.
-DrD-
> Next (hopefully last??) update:
> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>
> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>
> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>
>
> These comments in flags.m4 are a bit misleading and not really true:
> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
> # FIXME: clean this up, and/or move it elsewhere.
>
> So, I removed them...
>
> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>
>
>
> Testing:
>
> I now have two system configurations I'm testing with:
> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>
> System 1 tests:
> $ sudo xcode-select -switch /Applications/Xcode.app
> $ make clean; sh ./configure; make images
> ...
> 00:09:17 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
>
> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
> ...
> 00:13:37 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
> (Note that building with Xcode 5/clang is faster...)
>
>
> $ sudo xcode-select -switch /Applications/old/Xcode4.app
> $ make clean; sh ./configure; make images
> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>
>
> $ make clean; sh ./configure --with-toolchain-type=clang; make images
> ...
> 00:10:54 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
>
> System 2 tests:
> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
> ...
> 00:20:26 TOTAL
> -------------------------
> Finished building OpenJDK for target 'images'
>
>
> Closed JDK (images only, deploy/install expected to fail)
> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
> ...
> 00:10:05 TOTAL
> -------------------------
> Finished building Java(TM) for target 'images'
>
> -DrD-
>
From david.holmes at oracle.com Thu Jun 12 01:44:17 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Jun 2014 11:44:17 +1000
Subject: Fwd: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
In-Reply-To: <173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
<173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
Message-ID: <539905F1.7060509@oracle.com>
Hi David,
In saproc.make:
Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you
are adding is nothing to do with the ARCH setting. If none of the
existing variables are suitable perhaps just add SA_CFLAGS?
If SDKROOT is not set is the path one that would normally exist? In
particular does it exist on all our JPRT clients?
Thanks,
David H.
On 12/06/2014 6:06 AM, David DeHaven wrote:
>
> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this?
>
> The hotspot specific changes are here:
> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/
>
> Also, is there a problem if I push these through jdk9/build instead of going through hotspot?
>
> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results.
>
> -DrD-
>
>> From: David DeHaven <david.dehaven at oracle.com>
>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
>> Date: June 4, 2014 16:01:29 PDT
>> To: build-dev build-dev <build-dev at openjdk.java.net>
>>
>>
>> Next (hopefully last??) update:
>> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>>
>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>>
>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>>
>>
>> These comments in flags.m4 are a bit misleading and not really true:
>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
>> # FIXME: clean this up, and/or move it elsewhere.
>>
>> So, I removed them...
>>
>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>>
>>
>>
>> Testing:
>>
>> I now have two system configurations I'm testing with:
>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>>
>> System 1 tests:
>> $ sudo xcode-select -switch /Applications/Xcode.app
>> $ make clean; sh ./configure; make images
>> ...
>> 00:09:17 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>>
>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
>> ...
>> 00:13:37 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>> (Note that building with Xcode 5/clang is faster...)
>>
>>
>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>> $ make clean; sh ./configure; make images
>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>>
>>
>> $ make clean; sh ./configure --with-toolchain-type=clang; make images
>> ...
>> 00:10:54 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>>
>> System 2 tests:
>> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>> ...
>> 00:20:26 TOTAL
>> -------------------------
>> Finished building OpenJDK for target 'images'
>>
>>
>> Closed JDK (images only, deploy/install expected to fail)
>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>> ...
>> 00:10:05 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>> -DrD-
>>
>
From david.holmes at oracle.com Thu Jun 12 01:55:25 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Jun 2014 11:55:25 +1000
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <5398D9E9.6010608@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<539683D4.9030508@oracle.com> <5398D9E9.6010608@oracle.com>
Message-ID: <5399088D.8060607@oracle.com>
Hi Dan,
My only nit would be to use a CountDownLatch rather than roll your own
via wait/notify :)
Cheers,
David
On 12/06/2014 8:36 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> Let's try this hopefully one last time:
>
> http://cr.openjdk.java.net/~dcubed/8046287-webrev/1-jdk9-hs-rt/
> https://bugs.openjdk.java.net/browse/JDK-8046287
>
> Changes relative to the ORIGINAL version of the test:
>
> - added a new header waiting pattern to catch the case where
> the target thread waiting on a condition (like a VM op)
> - add synchronization to the start-up of the contending threads
> so that we don't start sampling while the contending threads
> are initializing
> - add sanity check for observing only two "ContendingThread-*"
> stack traces
>
> - rename some variables to make their use more clear
> - update/add various comments
> - add counters for the various checks and report a summary
> of all the sampling runs
> - issue a warning if the specific scenario encountered by
> the original bug (8036823) is never seen
>
> Testing:
>
> - JPRT test run of the test using product and fastdebug
> bits on all the usual platforms
>
> - 3600 sample run with fastdebug bits:
> INFO: Summary for all samples:
> INFO: both_running_cnt=0
> INFO: both_waiting_cnt=0
> INFO: contended_cnt=2005
> INFO: one_waiting_cnt=1405
> INFO: uncontended_cnt=190
>
> - 3600 sample run with fastdebug bits w/ -Xcomp:
> INFO: Summary for all samples:
> INFO: both_running_cnt=0
> INFO: both_waiting_cnt=0
> INFO: contended_cnt=1867
> INFO: one_waiting_cnt=1548
> INFO: uncontended_cnt=185
>
> - 3600 sample run with fastdebug bits w/ -Xcomp -XX:+DeoptimizeALot:
> INFO: Summary for all samples:
> INFO: both_running_cnt=46
> INFO: both_waiting_cnt=0
> INFO: contended_cnt=3135
> INFO: one_waiting_cnt=3
> INFO: uncontended_cnt=416
>
> The contended_cnt is where we're hitting the original
> bug's scenario and we've got great coverage there.
> The other counts reflect how often we hit the edge
> cases...
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>
>
> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Nightly testing has revealed a bug in the test that reproduces
>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>
>> Here's the webrev URL for the minor tweak to catch yet more
>> variation of the waiting pattern:
>>
>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>
>> Thanks to Vladimir K for reporting the test failure and for
>> providing the right details in the bug report.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>> One more round of review after refactoring the test based on comments
>>> from David H and Serguei.
>>>
>>> Here's the webrev for this round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>
>>> Had to change the default sample size from 30 -> 15 in order to
>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>
>>>> Here's the webrev URL for the next round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>
>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>> The new test has been run with the fix via JPRT and passes on all
>>>> JPRT platforms. The new test has also been run without the fix and
>>>> fails on most platforms. Since the default sample size is just 30,
>>>> it is possible to get 30 runs in a row without failing.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>> This is a simple fix for incorrect lock state.
>>>>>
>>>>> The timing on setting thread's pending monitor can result stack
>>>>> trace dump reporting incorrect lock state. The solution is to check
>>>>> the monitor's owner, if the owner is other than the current thread,
>>>>> then the monitor, is or is in process of being, set the pending
>>>>> monitor of current thread.
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
From daniel.daugherty at oracle.com Thu Jun 12 02:14:02 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 11 Jun 2014 20:14:02 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <5399088D.8060607@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<539683D4.9030508@oracle.com> <5398D9E9.6010608@oracle.com>
<5399088D.8060607@oracle.com>
Message-ID: <53990CEA.2010604@oracle.com>
Thanks for the very fast review!
Would you be OK if I just went with what I have since I've tested
that thoroughly? I've burned quite a few cycles on the original bug
and this test and I'd like to get back to my primary task...
Dan
On 6/11/14 7:55 PM, David Holmes wrote:
> Hi Dan,
>
> My only nit would be to use a CountDownLatch rather than roll your own
> via wait/notify :)
>
> Cheers,
> David
>
> On 12/06/2014 8:36 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Let's try this hopefully one last time:
>>
>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/1-jdk9-hs-rt/
>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>
>> Changes relative to the ORIGINAL version of the test:
>>
>> - added a new header waiting pattern to catch the case where
>> the target thread waiting on a condition (like a VM op)
>> - add synchronization to the start-up of the contending threads
>> so that we don't start sampling while the contending threads
>> are initializing
>> - add sanity check for observing only two "ContendingThread-*"
>> stack traces
>>
>> - rename some variables to make their use more clear
>> - update/add various comments
>> - add counters for the various checks and report a summary
>> of all the sampling runs
>> - issue a warning if the specific scenario encountered by
>> the original bug (8036823) is never seen
>>
>> Testing:
>>
>> - JPRT test run of the test using product and fastdebug
>> bits on all the usual platforms
>>
>> - 3600 sample run with fastdebug bits:
>> INFO: Summary for all samples:
>> INFO: both_running_cnt=0
>> INFO: both_waiting_cnt=0
>> INFO: contended_cnt=2005
>> INFO: one_waiting_cnt=1405
>> INFO: uncontended_cnt=190
>>
>> - 3600 sample run with fastdebug bits w/ -Xcomp:
>> INFO: Summary for all samples:
>> INFO: both_running_cnt=0
>> INFO: both_waiting_cnt=0
>> INFO: contended_cnt=1867
>> INFO: one_waiting_cnt=1548
>> INFO: uncontended_cnt=185
>>
>> - 3600 sample run with fastdebug bits w/ -Xcomp -XX:+DeoptimizeALot:
>> INFO: Summary for all samples:
>> INFO: both_running_cnt=46
>> INFO: both_waiting_cnt=0
>> INFO: contended_cnt=3135
>> INFO: one_waiting_cnt=3
>> INFO: uncontended_cnt=416
>>
>> The contended_cnt is where we're hitting the original
>> bug's scenario and we've got great coverage there.
>> The other counts reflect how often we hit the edge
>> cases...
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> Nightly testing has revealed a bug in the test that reproduces
>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>
>>> Here's the webrev URL for the minor tweak to catch yet more
>>> variation of the waiting pattern:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>
>>> Thanks to Vladimir K for reporting the test failure and for
>>> providing the right details in the bug report.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>> One more round of review after refactoring the test based on comments
>>>> from David H and Serguei.
>>>>
>>>> Here's the webrev for this round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>
>>>> Had to change the default sample size from 30 -> 15 in order to
>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>
>>>>> Here's the webrev URL for the next round:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>
>>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>> it is possible to get 30 runs in a row without failing.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>> This is a simple fix for incorrect lock state.
>>>>>>
>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>> trace dump reporting incorrect lock state. The solution is to check
>>>>>> the monitor's owner, if the owner is other than the current thread,
>>>>>> then the monitor, is or is in process of being, set the pending
>>>>>> monitor of current thread.
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
From david.holmes at oracle.com Thu Jun 12 02:38:11 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Jun 2014 12:38:11 +1000
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <53990CEA.2010604@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<539683D4.9030508@oracle.com> <5398D9E9.6010608@oracle.com>
<5399088D.8060607@oracle.com> <53990CEA.2010604@oracle.com>
Message-ID: <53991293.6010507@oracle.com>
On 12/06/2014 12:14 PM, Daniel D. Daugherty wrote:
> Thanks for the very fast review!
>
> Would you be OK if I just went with what I have since I've tested
> that thoroughly? I've burned quite a few cycles on the original bug
> and this test and I'd like to get back to my primary task...
Sure, it was a nit :)
David
> Dan
>
>
> On 6/11/14 7:55 PM, David Holmes wrote:
>> Hi Dan,
>>
>> My only nit would be to use a CountDownLatch rather than roll your own
>> via wait/notify :)
>>
>> Cheers,
>> David
>>
>> On 12/06/2014 8:36 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> Let's try this hopefully one last time:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/1-jdk9-hs-rt/
>>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>>
>>> Changes relative to the ORIGINAL version of the test:
>>>
>>> - added a new header waiting pattern to catch the case where
>>> the target thread waiting on a condition (like a VM op)
>>> - add synchronization to the start-up of the contending threads
>>> so that we don't start sampling while the contending threads
>>> are initializing
>>> - add sanity check for observing only two "ContendingThread-*"
>>> stack traces
>>>
>>> - rename some variables to make their use more clear
>>> - update/add various comments
>>> - add counters for the various checks and report a summary
>>> of all the sampling runs
>>> - issue a warning if the specific scenario encountered by
>>> the original bug (8036823) is never seen
>>>
>>> Testing:
>>>
>>> - JPRT test run of the test using product and fastdebug
>>> bits on all the usual platforms
>>>
>>> - 3600 sample run with fastdebug bits:
>>> INFO: Summary for all samples:
>>> INFO: both_running_cnt=0
>>> INFO: both_waiting_cnt=0
>>> INFO: contended_cnt=2005
>>> INFO: one_waiting_cnt=1405
>>> INFO: uncontended_cnt=190
>>>
>>> - 3600 sample run with fastdebug bits w/ -Xcomp:
>>> INFO: Summary for all samples:
>>> INFO: both_running_cnt=0
>>> INFO: both_waiting_cnt=0
>>> INFO: contended_cnt=1867
>>> INFO: one_waiting_cnt=1548
>>> INFO: uncontended_cnt=185
>>>
>>> - 3600 sample run with fastdebug bits w/ -Xcomp -XX:+DeoptimizeALot:
>>> INFO: Summary for all samples:
>>> INFO: both_running_cnt=46
>>> INFO: both_waiting_cnt=0
>>> INFO: contended_cnt=3135
>>> INFO: one_waiting_cnt=3
>>> INFO: uncontended_cnt=416
>>>
>>> The contended_cnt is where we're hitting the original
>>> bug's scenario and we've got great coverage there.
>>> The other counts reflect how often we hit the edge
>>> cases...
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> Nightly testing has revealed a bug in the test that reproduces
>>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>>
>>>> Here's the webrev URL for the minor tweak to catch yet more
>>>> variation of the waiting pattern:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>>
>>>> Thanks to Vladimir K for reporting the test failure and for
>>>> providing the right details in the bug report.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>>> One more round of review after refactoring the test based on comments
>>>>> from David H and Serguei.
>>>>>
>>>>> Here's the webrev for this round:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>>
>>>>> Had to change the default sample size from 30 -> 15 in order to
>>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>>
>>>>>> Here's the webrev URL for the next round:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>>
>>>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>>> it is possible to get 30 runs in a row without failing.
>>>>>>
>>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>>> This is a simple fix for incorrect lock state.
>>>>>>>
>>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>>> trace dump reporting incorrect lock state. The solution is to check
>>>>>>> the monitor's owner, if the owner is other than the current thread,
>>>>>>> then the monitor, is or is in process of being, set the pending
>>>>>>> monitor of current thread.
>>>>>>>
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
From nils.eliasson at oracle.com Thu Jun 12 08:26:18 2014
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 12 Jun 2014 10:26:18 +0200
Subject: [8u20] RFR(XXS): JDK-8040244
compiler/whitebox/IsMethodCompilableTest.java fails
Message-ID: <5399642A.5060707@oracle.com>
Hi,
I would like to request a 8u20 backport of JDK-8040244.
The change was pushed to jdk 9 yesterday and has passed one nightly
without problems. The change applies to 8u without conflicts.
Master bug: https://bugs.openjdk.java.net/browse/JDK-8040244
Webrev: http://cr.openjdk.java.net/~neliasso/8040244/webrev.01/
Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/93a279538de3
Thanks,
Nils
From bengt.rutisson at oracle.com Thu Jun 12 08:54:21 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 12 Jun 2014 10:54:21 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <1402424676.2701.7.camel@cirrus>
References: <537C7264.70200@oracle.com>
<537DAA00.2010104@oracle.com> <537ED5FC.6080702@oracle.com>
<2198629.dbW8eWbo0l@ehelin-desktop> <538F35DE.1040802@oracle.com>
<1401978537.2592.5.camel@cirrus>
<5390D9F9.2080202@oracle.com> <5395A2DA.3000507@oracle.com>
<1402391343.2588.15.camel@cirrus> <5396FC14.5010705@oracle.com>
<1402424676.2701.7.camel@cirrus>
Message-ID: <53996ABD.5000003@oracle.com>
Hi again,
Erik noticed two things. I had done an unnecessary change in
g1CollectedHeap.cpp and there were issues with getting the correct GC ID
for logging an aborted concurrent cycle in G1.
I've reverted the unnecessary change in g1CollectedHeap.cpp and I
suggest to solve the issue with the aborted concurrent cycle by keeping
track of the GC id that we abort and use that for logging.
Here's an updated webrev:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.07/
Here's the diff copared to the last one:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.06-07.diff/
Thanks,
Bengt
On 2014-06-10 20:24, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2014-06-10 at 14:37 +0200, Bengt Rutisson wrote:
>> Hi Thomas,
>>
>> Thanks for looking at this again!
>>> Regarding the test and possible backporting: the test currently assumes
>>> that gc id printing is on by default. Wouldn't it be better to specify
>>> +/-PrintGCId in the these tests to make sure it also works with
>>> different default settings, and possibly one run checking default
>>> settings?
>> Good point. I updated the test:
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/test/gc/logging/TestGCId.java.html
>>
>> Full new webrev (only the test has changed):
>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/
>>
>>> You mentioned somewhere that you want to backport this change to 8u with
>>> the default value of PrintGCid to be false (iirc) too.
>> Right. That is my plan. I will need to send out a separate review for
>> that since I will do a code change (the default value in globals.hpp),
>> so we can discuss the details during that review. With the new test the
>> only required change is to switch verify method for the default case.
> Okay. Looks good to me.
>
> Thomas
>
From dan at danny.cz Thu Jun 12 09:05:13 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Thu, 12 Jun 2014 11:05:13 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
Message-ID: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
Hello,
this the last and largest part of my changes required on s390 (32-bit)
to build OpenJDK out of the box. The MIN2/MAX2 functions are implemented
using templates and require both arguments to be of the same type. This
is a problem when one parameter is of size_t type and the second of
uintx type and the platform has size_t defined as eg. unsigned long as
on s390 (32-bit).
As a solution [1] I chose to typecast the smaller type (uintx) to size_t
which is of same or larger size.
[1] http://fedora.danny.cz/openjdk/size_t/webrev/
Note: I'm Red Hat employee (dhorak at redhat.com), so I should be covered
by Red Hat's CLA for my contributions.
With regards
Dan
From zhengyu.gu at oracle.com Thu Jun 12 12:34:37 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Thu, 12 Jun 2014 08:34:37 -0400
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
In-Reply-To: <5398E48E.9020201@oracle.com>
References: <537E4DB2.5020602@oracle.com> <5398E48E.9020201@oracle.com>
Message-ID: <53999E5D.9030403@oracle.com>
Coleen,
Thanks for the review.
On 6/11/2014 7:21 PM, Coleen Phillimore wrote:
>
> Hi Zhengyu,
>
> I have early feedback but I haven't looked at the new files yet.
> Nothing major. I like the new code and I'm glad you could add NMT
> tracking to vmError reporting.
>
> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/solaris/vm/os_solaris.cpp.udiff.html
>
>
> + bool os::unsetenv(const char* name) {
> + assert(name != NULL, "Null pointer");
> + return (::unsetenv(name) == 0);
> + }
> +
>
> Can you add this to os_posix.cpp instead? Someday this duplicate code
> will be consolidated so it can start in posix even though it's not posix.
>
OK. I assume that aix can also use os_posix functions, right?
> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/windows/vm/os_windows.cpp.udiff.html
>
>
> I thought the original comment was more descriptive. Is it still a
> workaround?
>
I think we still need this workaround. Auto-merge overwrote Christian's
comment, I will restore.
> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/share/vm/runtime/arguments.cpp.html
>
>
> Can you factor lines 3596-3623 into a function like verify_nmt_flag?
> Is it that you already know what nmt level is used from the launcher
> and are just checking consistency and initializing here? These
> cascading if() code checking options gets too long if you're not careful.
Will do.
>
> In memReporter.hpp
>
> A short comment before each class what they are for and how you would
> get to this code would be nice. I think they correspond to NMT
> settings (summary vs. detail). Mem*DiffReporter reports the
> difference between the current memory tracked and a previous snapshot
> it appears.
Will do.
>
>
> In memReporter.cpp
>
> Lines 302-311, you could have two functions that does this same
> calculation for these values so that it doesn't get broken. The same
> calculation appears 61 and 64.
>
> If you use size_t can you avoid eagerly scaling the amounts?
> amount_in_current_scale appears 66 times which is a lot. Can you only
> call the scaling when you print the amounts?
I think that is what I did. All calculations are done in byte scale,
only converts to current scale when checks amount > 0 in current scale,
and print the number.
> In MemTracker.hpp
>
> Line 109, I think you can assert that the JVM is single threaded.
>
What's the reliable method to check JVM single thread mode? I tried in
early NMT implementation, but it was not reliable.
Thanks,
-Zhengyu
> That's as far as I got today. This looks good!
>
> Coleen
>
> On 5/22/14, 3:19 PM, Zhengyu Gu wrote:
>> This is significant rework of native memory tracking introduced in
>> earlier releases.
>>
>> The goal of this enhancement is to improve scalability, from both
>> tracking memory and CPU usage perspectives, so it can scale well with
>> increased memory allocation in large applications.
>>
>> The enhancement is mainly focused on malloc memory tracking, whose
>> activities are several magnitude higher than virtual memory, and was
>> the main bottleneck in early implementation.
>>
>> Instead of using book keeping records for tracking malloc activities,
>> new implementation co-locates tracking data along side with user data
>> by using a prefixed header. The header size is 8 bytes on 32-bit
>> systems and 16 bytes on 64-bit systems, which ensure that user data
>> also align properly.
>>
>> Virtual memory tracking still uses book keeping records, and
>> ThreadCritical lock is always acquired to alter the records and
>> related data structures.
>>
>> Summary tracking data is maintained in static data structures, via
>> atomic operations. Malloc detail tracking call stacks are maintained
>> in a lock free hashtable.
>>
>> The key improvements:
>> 1. Up-to-date tracking report.
>> 2. Detail tracking now shows multiple call frames. Number of frames
>> is compilation time decision, currently default to 4.
>> 3. Malloc tracking is lock free.
>> 4. Tracking summary is reported in hs_err file when native memory
>> tracking is enabled.
>> 5. Query is faster, uses little memory and need a very little process.
>>
>> The drawback is that, malloc tracking header is always needed if
>> native memory tracking has ever been enabled, even after tracking is
>> shutdown.
>>
>> Impacts:
>> The most noticeable impact for JVM developers, is that Arena now
>> also take memory type as constructor parameter, besides the new
>> operators.
>> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode)
>> Arena(mtCode)
>>
>> The webrev shows modification of about 60 files, but most of them are
>> due to tracking API changes, mainly due to tracking stack, now, is an
>> object, vs. a single pc.
>>
>> The most important files for this implementations are:
>>
>> memTracker.hpp/cpp
>> mallocTracker.hpp/cpp and mallocTracker.inline.hpp
>> virtualMemoryTracker.hpp/cpp
>> mallocSiteTable.hpp/cpp
>>
>> allocationSite.hpp
>> nativeCallStack.hpp/cpp
>> linkedlist.hpp
>>
>>
>> Tests:
>> - JPRT
>> - NMT test suite
>> - vm.quick.testlist
>> - Kitchensink stability test for 16+ days
>> - FMW
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028541
>> Webrev: http://cr.openjdk.java.net/~zgu/8028541/webrev.00/
>>
>> Thanks,
>>
>> -Zhengyu
>>
>
From roland.westrelin at oracle.com Thu Jun 12 12:36:13 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 12 Jun 2014 14:36:13 +0200
Subject: [8u20] 8032410: compiler/uncommontrap/TestStackBangRbp.java times out
on Solaris-Sparc V9
Message-ID: <86457131-4CF8-4A43-9545-6B4A9DF62C32@oracle.com>
8u20 backport request. The change was pushed to jdk9 almost 2.5 months ago and testing hasn?t shown any problem. I was asked to backport this because it fixes an issue reported by a customer (https://bugs.openjdk.java.net/browse/JDK-8035399)
The change applies cleanly to 8u.
https://bugs.openjdk.java.net/browse/JDK-8032410
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cfa802bad1d8
Roland.
From christian.thalinger at oracle.com Thu Jun 12 15:43:40 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 12 Jun 2014 08:43:40 -0700
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <5398C681.70209@oracle.com>
References: <5398C681.70209@oracle.com>
Message-ID: <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com>
+Mutex* ConstantPool::lock() {
+ // Use the lock from the metaspace in the rare instance we need to lock the entries
+ // in this cpool or its associated cache. Only used for setting invokedynamic cpCache
+ // entry.
+ return pool_holder()->class_loader_data()->metaspace_lock();
+}
I?d rather see this method removed completely and use the metaspace lock explicitly in ConstantPoolCacheEntry::set_method_handle_common. Otherwise it's confusing.
On Jun 11, 2014, at 2:13 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> Summary: Write klass and resolved_references constant pool fields lock free.
>
> The constant pool values that can change were already read lock free, through the cpSlot type (lsb set for Symbol vs. Klass) for JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other values that can change were moved to the resolved_references array, which is initialized to null. Non-null is the resolved value. With a couple uses of CAS, we can eliminate the need for the constant pool lock for the constant pool changes. Error handling also changes the tag but saving the resolution exception was done under the SystemDictionary_lock, so only the tag change needs a CAS.
>
> The only remaining use for the constant pool lock is updating the cpCache for invokedynamic. There are 4 fields that need to be consistent. These now use the metaspace lock associated with the class loader that owns the constant pool, which is only held briefly. I ran some performance tests written by Sergey Kuksenko which show no regression.
>
> Other testing - ran refworkload on linux x64 with no significant results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests, hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>
> Thanks,
> Coleen
>
>
From vladimir.kozlov at oracle.com Thu Jun 12 15:52:44 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 12 Jun 2014 08:52:44 -0700
Subject: [8u20] 8032410: compiler/uncommontrap/TestStackBangRbp.java times
out on Solaris-Sparc V9
In-Reply-To: <86457131-4CF8-4A43-9545-6B4A9DF62C32@oracle.com>
References: <86457131-4CF8-4A43-9545-6B4A9DF62C32@oracle.com>
Message-ID: <5399CCCC.1060906@oracle.com>
Good.
Vladimir
On 6/12/14 5:36 AM, Roland Westrelin wrote:
> 8u20 backport request. The change was pushed to jdk9 almost 2.5 months ago and testing hasn?t shown any problem. I was asked to backport this because it fixes an issue reported by a customer (https://bugs.openjdk.java.net/browse/JDK-8035399)
>
> The change applies cleanly to 8u.
> https://bugs.openjdk.java.net/browse/JDK-8032410
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cfa802bad1d8
>
> Roland.
>
From vladimir.kozlov at oracle.com Thu Jun 12 15:56:47 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 12 Jun 2014 08:56:47 -0700
Subject: [8u20] RFR(XXS): JDK-8040244
compiler/whitebox/IsMethodCompilableTest.java fails
In-Reply-To: <5399642A.5060707@oracle.com>
References: <5399642A.5060707@oracle.com>
Message-ID: <5399CDBF.6010804@oracle.com>
Looks good.
Vladimir
On 6/12/14 1:26 AM, Nils Eliasson wrote:
> Hi,
>
> I would like to request a 8u20 backport of JDK-8040244.
>
> The change was pushed to jdk 9 yesterday and has passed one nightly without problems. The change applies to 8u without
> conflicts.
>
> Master bug: https://bugs.openjdk.java.net/browse/JDK-8040244
> Webrev: http://cr.openjdk.java.net/~neliasso/8040244/webrev.01/
> Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/93a279538de3
>
> Thanks,
> Nils
From coleen.phillimore at oracle.com Thu Jun 12 15:57:57 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 12 Jun 2014 11:57:57 -0400
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com>
References: <5398C681.70209@oracle.com>
<5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com>
Message-ID: <5399CE05.2060806@oracle.com>
On 6/12/14, 11:43 AM, Christian Thalinger wrote:
> +Mutex* ConstantPool::lock() {
> + // Use the lock from the metaspace in the rare instance we need to lock the entries
> + // in this cpool or its associated cache. Only used for setting invokedynamic cpCache
> + // entry.
> + return pool_holder()->class_loader_data()->metaspace_lock();
> +}
>
> I?d rather see this method removed completely and use the metaspace
> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
> Otherwise it's confusing.
Ok, I can change that.
Coleen
>
> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
> wrote:
>
>> Summary: Write klass and resolved_references constant pool fields
>> lock free.
>>
>> The constant pool values that can change were already read lock free,
>> through the cpSlot type (lsb set for Symbol vs. Klass) for
>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other
>> values that can change were moved to the resolved_references array,
>> which is initialized to null. Non-null is the resolved value. With
>> a couple uses of CAS, we can eliminate the need for the constant pool
>> lock for the constant pool changes. Error handling also changes the
>> tag but saving the resolution exception was done under the
>> SystemDictionary_lock, so only the tag change needs a CAS.
>>
>> The only remaining use for the constant pool lock is updating the
>> cpCache for invokedynamic. There are 4 fields that need to be
>> consistent. These now use the metaspace lock associated with the
>> class loader that owns the constant pool, which is only held briefly.
>> I ran some performance tests written by Sergey Kuksenko which show
>> no regression.
>>
>> Other testing - ran refworkload on linux x64 with no significant
>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>
>> Thanks,
>> Coleen
>>
>>
>
From john.r.rose at oracle.com Thu Jun 12 16:57:12 2014
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 12 Jun 2014 09:57:12 -0700
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <5399CE05.2060806@oracle.com>
References: <5398C681.70209@oracle.com>
<5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com>
<5399CE05.2060806@oracle.com>
Message-ID: <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
Reviewed. This is a good change. The code is much cleaner. Thanks. ? John
On Jun 12, 2014, at 8:57 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>> +Mutex* ConstantPool::lock() {
>> + // Use the lock from the metaspace in the rare instance we need to lock the entries
>> + // in this cpool or its associated cache. Only used for setting invokedynamic cpCache
>> + // entry.
>> + return pool_holder()->class_loader_data()->metaspace_lock();
>> +}
>>
>> I?d rather see this method removed completely and use the metaspace lock explicitly in ConstantPoolCacheEntry::set_method_handle_common. Otherwise it's confusing.
>
> Ok, I can change that.
>
> Coleen
>
>>
>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> wrote:
>>
>>> Summary: Write klass and resolved_references constant pool fields lock free.
>>>
>>> The constant pool values that can change were already read lock free, through the cpSlot type (lsb set for Symbol vs. Klass) for JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other values that can change were moved to the resolved_references array, which is initialized to null. Non-null is the resolved value. With a couple uses of CAS, we can eliminate the need for the constant pool lock for the constant pool changes. Error handling also changes the tag but saving the resolution exception was done under the SystemDictionary_lock, so only the tag change needs a CAS.
>>>
>>> The only remaining use for the constant pool lock is updating the cpCache for invokedynamic. There are 4 fields that need to be consistent. These now use the metaspace lock associated with the class loader that owns the constant pool, which is only held briefly. I ran some performance tests written by Sergey Kuksenko which show no regression.
>>>
>>> Other testing - ran refworkload on linux x64 with no significant results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests, hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/ <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>
>
From david.dehaven at oracle.com Thu Jun 12 16:58:30 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 12 Jun 2014 09:58:30 -0700
Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
In-Reply-To: <539905F1.7060509@oracle.com>
References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
<173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
<539905F1.7060509@oracle.com>
Message-ID: <F56C5565-69B9-4833-9A7C-D6B0FFC92ED5@oracle.com>
Yes, I was going for convenience and minimizing disturbance. I'll change how the flags are passed.
If SDKROOT is unset then the paths point at the existing hard-coded paths in /System/Library/Frameworks, all SDKROOT does is prepend the SDK path and it's only set under certain conditions. JPRT has been perfectly happy with this change so far.
Note that this ugliness can go away when we remove the dependencies on the JavaNativeFoundation and JavaRuntimeSupport frameworks.
-DrD-
> Hi David,
>
> In saproc.make:
>
> Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you are adding is nothing to do with the ARCH setting. If none of the existing variables are suitable perhaps just add SA_CFLAGS?
>
> If SDKROOT is not set is the path one that would normally exist? In particular does it exist on all our JPRT clients?
>
> Thanks,
> David H.
>
> On 12/06/2014 6:06 AM, David DeHaven wrote:
>>
>> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this?
>>
>> The hotspot specific changes are here:
>> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/
>>
>> Also, is there a problem if I push these through jdk9/build instead of going through hotspot?
>>
>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results.
>>
>> -DrD-
>>
>>> From: David DeHaven <david.dehaven at oracle.com>
>>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
>>> Date: June 4, 2014 16:01:29 PDT
>>> To: build-dev build-dev <build-dev at openjdk.java.net>
>>>
>>>
>>> Next (hopefully last??) update:
>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>>>
>>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>>>
>>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>>>
>>>
>>> These comments in flags.m4 are a bit misleading and not really true:
>>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
>>> # FIXME: clean this up, and/or move it elsewhere.
>>>
>>> So, I removed them...
>>>
>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>>>
>>>
>>>
>>> Testing:
>>>
>>> I now have two system configurations I'm testing with:
>>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
>>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>>>
>>> System 1 tests:
>>> $ sudo xcode-select -switch /Applications/Xcode.app
>>> $ make clean; sh ./configure; make images
>>> ...
>>> 00:09:17 TOTAL
>>> -------------------------
>>> Finished building Java(TM) for target 'images'
>>>
>>>
>>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
>>> ...
>>> 00:13:37 TOTAL
>>> -------------------------
>>> Finished building Java(TM) for target 'images'
>>>
>>> (Note that building with Xcode 5/clang is faster...)
>>>
>>>
>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>>> $ make clean; sh ./configure; make images
>>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
>>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>>>
>>>
>>> $ make clean; sh ./configure --with-toolchain-type=clang; make images
>>> ...
>>> 00:10:54 TOTAL
>>> -------------------------
>>> Finished building Java(TM) for target 'images'
>>>
>>>
>>> System 2 tests:
>>> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>> ...
>>> 00:20:26 TOTAL
>>> -------------------------
>>> Finished building OpenJDK for target 'images'
>>>
>>>
>>> Closed JDK (images only, deploy/install expected to fail)
>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>> ...
>>> 00:10:05 TOTAL
>>> -------------------------
>>> Finished building Java(TM) for target 'images'
>>>
>>> -DrD-
>>>
>>
From alejandro.murillo at oracle.com Thu Jun 12 17:44:53 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 12 Jun 2014 11:44:53 -0600
Subject: Fwd: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
In-Reply-To: <173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
<173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
Message-ID: <5399E715.1060600@oracle.com>
On 6/11/2014 2:06 PM, David DeHaven wrote:
> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this?
>
> The hotspot specific changes are here:
> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/
>
> Also, is there a problem if I push these through jdk9/build instead of going through hotspot?
Hi, we recently had a serious problem by the lack of testing for this
kind of changes,
please push through a hotspot repo so that the appropriate nightly and
PIT testing
is done before it makes it to jdk9/dev
Thanks
Alejandro
>
> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results.
>
> -DrD-
>
>> From: David DeHaven<david.dehaven at oracle.com>
>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
>> Date: June 4, 2014 16:01:29 PDT
>> To: build-dev build-dev<build-dev at openjdk.java.net>
>>
>>
>> Next (hopefully last??) update:
>> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>>
>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>>
>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>>
>>
>> These comments in flags.m4 are a bit misleading and not really true:
>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
>> # FIXME: clean this up, and/or move it elsewhere.
>>
>> So, I removed them...
>>
>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>>
>>
>>
>> Testing:
>>
>> I now have two system configurations I'm testing with:
>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>>
>> System 1 tests:
>> $ sudo xcode-select -switch /Applications/Xcode.app
>> $ make clean; sh ./configure; make images
>> ...
>> 00:09:17 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>>
>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
>> ...
>> 00:13:37 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>> (Note that building with Xcode 5/clang is faster...)
>>
>>
>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>> $ make clean; sh ./configure; make images
>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>>
>>
>> $ make clean; sh ./configure --with-toolchain-type=clang; make images
>> ...
>> 00:10:54 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>>
>> System 2 tests:
>> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>> ...
>> 00:20:26 TOTAL
>> -------------------------
>> Finished building OpenJDK for target 'images'
>>
>>
>> Closed JDK (images only, deploy/install expected to fail)
>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>> ...
>> 00:10:05 TOTAL
>> -------------------------
>> Finished building Java(TM) for target 'images'
>>
>> -DrD-
>>
--
Alejandro
From vladimir.kozlov at oracle.com Thu Jun 12 18:57:42 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 12 Jun 2014 11:57:42 -0700
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
Message-ID: <5399F826.4060409@oracle.com>
Thank you, Dan
I think casting is acceptable solution. Someone in GC group should
review and sponsor this since you touched GC code mostly.
Regards,
Vladimir
On 6/12/14 2:05 AM, Dan Hor?k wrote:
> Hello,
>
> this the last and largest part of my changes required on s390 (32-bit)
> to build OpenJDK out of the box. The MIN2/MAX2 functions are implemented
> using templates and require both arguments to be of the same type. This
> is a problem when one parameter is of size_t type and the second of
> uintx type and the platform has size_t defined as eg. unsigned long as
> on s390 (32-bit).
>
> As a solution [1] I chose to typecast the smaller type (uintx) to size_t
> which is of same or larger size.
>
> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>
> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be covered
> by Red Hat's CLA for my contributions.
>
>
> With regards
>
> Dan
>
From jesper.wilhelmsson at oracle.com Thu Jun 12 19:49:40 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 12 Jun 2014 21:49:40 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <5399F826.4060409@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com>
Message-ID: <539A0454.5030906@oracle.com>
Hi,
Which repository is the patch built on? Since it is mostly GC code it would be
good if it goes in through jdk9/hs-gc.
The changes looks good in the webrev, but the patch did not apply to a recent
jdk9/hs-gc. Especially the collector policy code has changed a lot recently.
I would prefer to look at the changes applied in my workspace before approving
it, so if you could update to a recent hs-gc it would be great.
Thanks!
/Jesper
Vladimir Kozlov skrev 12/6/14 20:57:
> Thank you, Dan
>
> I think casting is acceptable solution. Someone in GC group should review and
> sponsor this since you touched GC code mostly.
>
> Regards,
> Vladimir
>
> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>> Hello,
>>
>> this the last and largest part of my changes required on s390 (32-bit)
>> to build OpenJDK out of the box. The MIN2/MAX2 functions are implemented
>> using templates and require both arguments to be of the same type. This
>> is a problem when one parameter is of size_t type and the second of
>> uintx type and the platform has size_t defined as eg. unsigned long as
>> on s390 (32-bit).
>>
>> As a solution [1] I chose to typecast the smaller type (uintx) to size_t
>> which is of same or larger size.
>>
>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>
>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be covered
>> by Red Hat's CLA for my contributions.
>>
>>
>> With regards
>>
>> Dan
>>
From dan at danny.cz Thu Jun 12 20:31:49 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Thu, 12 Jun 2014 22:31:49 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539A0454.5030906@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
Message-ID: <20140612223149.522407dfa69564ac1cfe0446@danny.cz>
On Thu, 12 Jun 2014 21:49:40 +0200
Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> Hi,
>
> Which repository is the patch built on? Since it is mostly GC code it
> would be good if it goes in through jdk9/hs-gc.
>
> The changes looks good in the webrev, but the patch did not apply to
> a recent jdk9/hs-gc. Especially the collector policy code has changed
> a lot recently.
>
> I would prefer to look at the changes applied in my workspace before
> approving it, so if you could update to a recent hs-gc it would be
> great.
I have used http://hg.openjdk.java.net/jdk9/dev (+ my previous 2
patches on top) as source, but shouldn't take long to refresh the patch
for the hs-gc tree. It's not easy for an outsider to find the right
repo :-)
Dan
> Thanks!
> /Jesper
>
> Vladimir Kozlov skrev 12/6/14 20:57:
> > Thank you, Dan
> >
> > I think casting is acceptable solution. Someone in GC group should
> > review and sponsor this since you touched GC code mostly.
> >
> > Regards,
> > Vladimir
> >
> > On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >> Hello,
> >>
> >> this the last and largest part of my changes required on s390
> >> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2 functions
> >> are implemented using templates and require both arguments to be
> >> of the same type. This is a problem when one parameter is of
> >> size_t type and the second of uintx type and the platform has
> >> size_t defined as eg. unsigned long as on s390 (32-bit).
> >>
> >> As a solution [1] I chose to typecast the smaller type (uintx) to
> >> size_t which is of same or larger size.
> >>
> >> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>
> >> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
> >> covered by Red Hat's CLA for my contributions.
> >>
> >>
> >> With regards
> >>
> >> Dan
> >>
From serguei.spitsyn at oracle.com Thu Jun 12 20:57:59 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Jun 2014 13:57:59 -0700
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <5398D9E9.6010608@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<539683D4.9030508@oracle.com> <5398D9E9.6010608@oracle.com>
Message-ID: <539A1457.4000001@oracle.com>
Hi Dan,
Sorry for the latency.
As I understood, you put more control to the test for stability which is
good.
It is not easy to follow all the details, but I do not see any issues.
Ship it! :)
Thanks,
Serguei
On 6/11/14 3:36 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> Let's try this hopefully one last time:
>
> http://cr.openjdk.java.net/~dcubed/8046287-webrev/1-jdk9-hs-rt/
> https://bugs.openjdk.java.net/browse/JDK-8046287
>
> Changes relative to the ORIGINAL version of the test:
>
> - added a new header waiting pattern to catch the case where
> the target thread waiting on a condition (like a VM op)
> - add synchronization to the start-up of the contending threads
> so that we don't start sampling while the contending threads
> are initializing
> - add sanity check for observing only two "ContendingThread-*"
> stack traces
>
> - rename some variables to make their use more clear
> - update/add various comments
> - add counters for the various checks and report a summary
> of all the sampling runs
> - issue a warning if the specific scenario encountered by
> the original bug (8036823) is never seen
>
> Testing:
>
> - JPRT test run of the test using product and fastdebug
> bits on all the usual platforms
>
> - 3600 sample run with fastdebug bits:
> INFO: Summary for all samples:
> INFO: both_running_cnt=0
> INFO: both_waiting_cnt=0
> INFO: contended_cnt=2005
> INFO: one_waiting_cnt=1405
> INFO: uncontended_cnt=190
>
> - 3600 sample run with fastdebug bits w/ -Xcomp:
> INFO: Summary for all samples:
> INFO: both_running_cnt=0
> INFO: both_waiting_cnt=0
> INFO: contended_cnt=1867
> INFO: one_waiting_cnt=1548
> INFO: uncontended_cnt=185
>
> - 3600 sample run with fastdebug bits w/ -Xcomp -XX:+DeoptimizeALot:
> INFO: Summary for all samples:
> INFO: both_running_cnt=46
> INFO: both_waiting_cnt=0
> INFO: contended_cnt=3135
> INFO: one_waiting_cnt=3
> INFO: uncontended_cnt=416
>
> The contended_cnt is where we're hitting the original
> bug's scenario and we've got great coverage there.
> The other counts reflect how often we hit the edge
> cases...
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
>
>
> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Nightly testing has revealed a bug in the test that reproduces
>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>
>> Here's the webrev URL for the minor tweak to catch yet more
>> variation of the waiting pattern:
>>
>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>
>> Thanks to Vladimir K for reporting the test failure and for
>> providing the right details in the bug report.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>> One more round of review after refactoring the test based on comments
>>> from David H and Serguei.
>>>
>>> Here's the webrev for this round:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>
>>> Had to change the default sample size from 30 -> 15 in order to
>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>
>>>> Here's the webrev URL for the next round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>
>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>> The new test has been run with the fix via JPRT and passes on all
>>>> JPRT platforms. The new test has also been run without the fix and
>>>> fails on most platforms. Since the default sample size is just 30,
>>>> it is possible to get 30 runs in a row without failing.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>> This is a simple fix for incorrect lock state.
>>>>>
>>>>> The timing on setting thread's pending monitor can result stack
>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>> check the monitor's owner, if the owner is other than the current
>>>>> thread, then the monitor, is or is in process of being, set the
>>>>> pending monitor of current thread.
>>>>>
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
From coleen.phillimore at oracle.com Thu Jun 12 20:58:31 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 12 Jun 2014 16:58:31 -0400
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
References: <5398C681.70209@oracle.com>
<5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com>
<5399CE05.2060806@oracle.com>
<121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
Message-ID: <539A1477.4030406@oracle.com>
Thank you, John! Christian suggested I take out ConstantPool::lock()
and while doing so I discovered I was still using the unsafe
ConstantPool::unresolved_klass_at() call. So I replaced these with
ConstantPool::klass_name_at() which is safe.
Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking
the metaspace_lock() must not check for safepoints.
I make Chris's changes and fixed these problems and retested. Most
files are unchanged, but here is the updated webrev.
I didn't mention before that this change saves 152 bytes per class.
http://cr.openjdk.java.net/~coleenp/8026977_2/
Thanks!
Coleen
On 6/12/14, 12:57 PM, John Rose wrote:
> Reviewed. This is a good change. The code is much cleaner. Thanks. ? John
>
> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>> +Mutex* ConstantPool::lock() {
>>> + // Use the lock from the metaspace in the rare instance we need to lock the entries
>>> + // in this cpool or its associated cache. Only used for setting invokedynamic cpCache
>>> + // entry.
>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>> +}
>>>
>>> I?d rather see this method removed completely and use the metaspace lock explicitly in ConstantPoolCacheEntry::set_method_handle_common. Otherwise it's confusing.
>> Ok, I can change that.
>>
>> Coleen
>>
>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> wrote:
>>>
>>>> Summary: Write klass and resolved_references constant pool fields lock free.
>>>>
>>>> The constant pool values that can change were already read lock free, through the cpSlot type (lsb set for Symbol vs. Klass) for JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other values that can change were moved to the resolved_references array, which is initialized to null. Non-null is the resolved value. With a couple uses of CAS, we can eliminate the need for the constant pool lock for the constant pool changes. Error handling also changes the tag but saving the resolution exception was done under the SystemDictionary_lock, so only the tag change needs a CAS.
>>>>
>>>> The only remaining use for the constant pool lock is updating the cpCache for invokedynamic. There are 4 fields that need to be consistent. These now use the metaspace lock associated with the class loader that owns the constant pool, which is only held briefly. I ran some performance tests written by Sergey Kuksenko which show no regression.
>>>>
>>>> Other testing - ran refworkload on linux x64 with no significant results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests, hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/ <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
From mikael.vidstedt at oracle.com Thu Jun 12 21:18:49 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 12 Jun 2014 14:18:49 -0700
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <5397EEF7.5050006@oracle.com>
References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com>
<5397EEF7.5050006@oracle.com>
Message-ID: <539A1939.80103@oracle.com>
I have now verified that the changes work just fine for the platforms we
build and test - both from the top level and when building hotspot only.
Taking suggestions on other tests to perform. And it would be great if
somebody could test the changes on on aix/ppc.
So, kindly asking for "real"/final reviews of the changes:
top:
http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
hotspot:
http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
Cheers,
Mikael
On 2014-06-10 22:53, Mikael Vidstedt wrote:
>
> David,
>
> Thanks for the feedback. Essentially the logic in the
> make/<os>/makefiles/defs.make files needs to recognize and deal with
> two different use cases:
>
> 1. ARCH being set by the JDK build system to the value of
> OPENJDK_TARGET_CPU_ARCH, or
> 2. no ARCH being set, in which case it needs to be populated -
> typically from uname
>
> Since Solaris and bsd both override ARCH they do not care about
> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>
> Linux/x86 is where most of the difference (and confusion) is, but I
> think aix/ppc64 will also change slightly since the ARCH value will go
> from ppc64 to ppc. I've tried to make the relevant changes, but I
> cannot verify that they actually work. cc:ing the ppc-aix list in the
> hope that somebody can help out with that.
>
>
> Summing it up, I have the following two webrevs:
>
> top:
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
> hotspot:
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>
> With these changes I can build the normal platforms, but more
> verification is needed - esp. building hotspot only. Meanwhile
> feedback is much appreciated!
>
> Cheers,
> Mikael
>
> On 2014-06-10 19:45, David Holmes wrote:
>> Hi Mikael,
>>
>> This seems a reasonable proposal to me. We have an over-abundance of
>> "arch" variables and values, so reducing that is a good aim.
>>
>> As you note the main flow-on effect here is that the hotspot
>> makefiles have to be updated for the cases where
>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so that
>> it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think only x86
>> has that issue.
>>
>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc both
>> internally and in the build artifacts and bundles!
>>
>> Cheers,
>> David
>>
>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>
>>> All,
>>>
>>> I need some feedback and comments on the below fix:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>> Webrev:
>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>
>>> Background:
>>>
>>> When configuring the hotspot build the build system sets up the ARCH
>>> variable to reflect the target cpu. Currently the value is initialized
>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name.
>>> For
>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The
>>> goal in the new (JDK) build system is to have the "legacy" value
>>> gradually removed in favor of the other variables.
>>>
>>> Discussion:
>>>
>>> The two candidate variables to base ARCH on are as far as I can tell
>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>> Hotspot build system to do its thing. Note: ARCH is currently
>>> ignored on
>>> solaris and bsd - it's overridden at the top of the respective
>>> make/<os>/makefiles/defs.make files.
>>>
>>> Before I go too far with this though I'd like to get some feedback on
>>> whether or not this is the right approach and what the exact value
>>> should be. Depending on the outcome of that the Hotspot build system
>>> may
>>> have to be updated for some platforms to support the new value(s).
>>>
>>> Thanks,
>>> Mikael
>>>
>
From daniel.daugherty at oracle.com Thu Jun 12 22:08:14 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 12 Jun 2014 16:08:14 -0600
Subject: RFR(XS) 8036823: Stack trace sometimes shows 'locked' instead
of 'waiting to lock'
In-Reply-To: <539A1457.4000001@oracle.com>
References: <537A0E1C.4070605@oracle.com>
<537ECC1A.1030409@oracle.com> <53874908.5070805@oracle.com>
<539683D4.9030508@oracle.com> <5398D9E9.6010608@oracle.com>
<539A1457.4000001@oracle.com>
Message-ID: <539A24CE.1030605@oracle.com>
Thanks!
Dan
On 6/12/14 2:57 PM, serguei.spitsyn at oracle.com wrote:
> Hi Dan,
>
> Sorry for the latency.
>
> As I understood, you put more control to the test for stability which
> is good.
> It is not easy to follow all the details, but I do not see any issues.
>
> Ship it! :)
>
> Thanks,
> Serguei
>
>
> On 6/11/14 3:36 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Let's try this hopefully one last time:
>>
>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/1-jdk9-hs-rt/
>> https://bugs.openjdk.java.net/browse/JDK-8046287
>>
>> Changes relative to the ORIGINAL version of the test:
>>
>> - added a new header waiting pattern to catch the case where
>> the target thread waiting on a condition (like a VM op)
>> - add synchronization to the start-up of the contending threads
>> so that we don't start sampling while the contending threads
>> are initializing
>> - add sanity check for observing only two "ContendingThread-*"
>> stack traces
>>
>> - rename some variables to make their use more clear
>> - update/add various comments
>> - add counters for the various checks and report a summary
>> of all the sampling runs
>> - issue a warning if the specific scenario encountered by
>> the original bug (8036823) is never seen
>>
>> Testing:
>>
>> - JPRT test run of the test using product and fastdebug
>> bits on all the usual platforms
>>
>> - 3600 sample run with fastdebug bits:
>> INFO: Summary for all samples:
>> INFO: both_running_cnt=0
>> INFO: both_waiting_cnt=0
>> INFO: contended_cnt=2005
>> INFO: one_waiting_cnt=1405
>> INFO: uncontended_cnt=190
>>
>> - 3600 sample run with fastdebug bits w/ -Xcomp:
>> INFO: Summary for all samples:
>> INFO: both_running_cnt=0
>> INFO: both_waiting_cnt=0
>> INFO: contended_cnt=1867
>> INFO: one_waiting_cnt=1548
>> INFO: uncontended_cnt=185
>>
>> - 3600 sample run with fastdebug bits w/ -Xcomp -XX:+DeoptimizeALot:
>> INFO: Summary for all samples:
>> INFO: both_running_cnt=46
>> INFO: both_waiting_cnt=0
>> INFO: contended_cnt=3135
>> INFO: one_waiting_cnt=3
>> INFO: uncontended_cnt=416
>>
>> The contended_cnt is where we're hitting the original
>> bug's scenario and we've got great coverage there.
>> The other counts reflect how often we hit the edge
>> cases...
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan
>>
>>
>> On 6/9/14 10:04 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> Nightly testing has revealed a bug in the test that reproduces
>>> nicely when these options are used: -Xcomp -XX:+DeoptimizeALot
>>>
>>> Here's the webrev URL for the minor tweak to catch yet more
>>> variation of the waiting pattern:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8046287-webrev/0-jdk9-hs-rt/
>>>
>>> Thanks to Vladimir K for reporting the test failure and for
>>> providing the right details in the bug report.
>>>
>>> Thanks, in advance, for any comments, questions or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/29/14 8:49 AM, Daniel D. Daugherty wrote:
>>>> One more round of review after refactoring the test based on comments
>>>> from David H and Serguei.
>>>>
>>>> Here's the webrev for this round:
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/2-jdk9-hs-rt/
>>>>
>>>> Had to change the default sample size from 30 -> 15 in order to
>>>> get the test to pass reliably on Solaris SPARC JPRT machines.
>>>>
>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/22/14 10:18 PM, Daniel D. Daugherty wrote:
>>>>> Zhengyu is tied up with some other work so I've taken on this fix.
>>>>>
>>>>> Here's the webrev URL for the next round:
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8036823-webrev/1-jdk9-hs-rt/
>>>>>
>>>>> The fix has been tested with vm.quick on all Aurora Adhoc platforms.
>>>>> The new test has been run with the fix via JPRT and passes on all
>>>>> JPRT platforms. The new test has also been run without the fix and
>>>>> fails on most platforms. Since the default sample size is just 30,
>>>>> it is possible to get 30 runs in a row without failing.
>>>>>
>>>>> Thanks, in advance, for any comments, questions or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 5/19/14 7:58 AM, Zhengyu Gu wrote:
>>>>>> This is a simple fix for incorrect lock state.
>>>>>>
>>>>>> The timing on setting thread's pending monitor can result stack
>>>>>> trace dump reporting incorrect lock state. The solution is to
>>>>>> check the monitor's owner, if the owner is other than the current
>>>>>> thread, then the monitor, is or is in process of being, set the
>>>>>> pending monitor of current thread.
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036823
>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8036823/webrev.00/
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
From mike.duigou at oracle.com Thu Jun 12 22:25:20 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 12 Jun 2014 15:25:20 -0700
Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches
for debug builds
Message-ID: <405FD050-2A45-4076-A4EE-B80D3E22F05A@oracle.com>
Hello all;
After some additional work this changeset appears to finally complete. This is your very last chance to review and further extend the saga!
jbsbug: https://bugs.openjdk.java.net/browse/JDK-8032045
webrev:http://cr.openjdk.java.net/~mduigou/JDK-8032045/9/webrev/
The changes since the last version remove some bash4.0-isms, backout an unnecessary change to the optimization level of HIGHEST and backout a change that was causing problems on MacOS. The later has been moved to a separate issue, 8046397.
I've completed product and fastdebug builds and test on all supported platforms including embedded and slowdebug builds on linux and macos with no apparent regressions.
Cheers,
Mike
From vladimir.kozlov at oracle.com Thu Jun 12 23:02:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 12 Jun 2014 16:02:31 -0700
Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety
switches for debug builds
In-Reply-To: <405FD050-2A45-4076-A4EE-B80D3E22F05A@oracle.com>
References: <405FD050-2A45-4076-A4EE-B80D3E22F05A@oracle.com>
Message-ID: <539A3187.8050205@oracle.com>
Looks good.
Vladimir
On 6/12/14 3:25 PM, Mike Duigou wrote:
> Hello all;
>
> After some additional work this changeset appears to finally complete. This is your very last chance to review and further extend the saga!
>
> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8032045
> webrev:http://cr.openjdk.java.net/~mduigou/JDK-8032045/9/webrev/
>
> The changes since the last version remove some bash4.0-isms, backout an unnecessary change to the optimization level of HIGHEST and backout a change that was causing problems on MacOS. The later has been moved to a separate issue, 8046397.
>
> I've completed product and fastdebug builds and test on all supported platforms including embedded and slowdebug builds on linux and macos with no apparent regressions.
>
> Cheers,
>
> Mike
>
From coleen.phillimore at oracle.com Fri Jun 13 02:43:34 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 12 Jun 2014 22:43:34 -0400
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
In-Reply-To: <53999E5D.9030403@oracle.com>
References: <537E4DB2.5020602@oracle.com> <5398E48E.9020201@oracle.com>
<53999E5D.9030403@oracle.com>
Message-ID: <539A6556.2070107@oracle.com>
Zhengyu,
In nativeCallStack.cpp why do you need
PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC? Can you change the print formats
to keep gcc from complaining?
Coleen
On 6/12/14, 8:34 AM, Zhengyu Gu wrote:
> Coleen,
>
> Thanks for the review.
>
> On 6/11/2014 7:21 PM, Coleen Phillimore wrote:
>>
>> Hi Zhengyu,
>>
>> I have early feedback but I haven't looked at the new files yet.
>> Nothing major. I like the new code and I'm glad you could add NMT
>> tracking to vmError reporting.
>>
>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/solaris/vm/os_solaris.cpp.udiff.html
>>
>>
>> + bool os::unsetenv(const char* name) {
>> + assert(name != NULL, "Null pointer");
>> + return (::unsetenv(name) == 0);
>> + }
>> +
>>
>> Can you add this to os_posix.cpp instead? Someday this duplicate
>> code will be consolidated so it can start in posix even though it's
>> not posix.
>>
> OK. I assume that aix can also use os_posix functions, right?
>
>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/windows/vm/os_windows.cpp.udiff.html
>>
>>
>> I thought the original comment was more descriptive. Is it still a
>> workaround?
>>
> I think we still need this workaround. Auto-merge overwrote
> Christian's comment, I will restore.
>
>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/share/vm/runtime/arguments.cpp.html
>>
>>
>> Can you factor lines 3596-3623 into a function like verify_nmt_flag?
>> Is it that you already know what nmt level is used from the launcher
>> and are just checking consistency and initializing here? These
>> cascading if() code checking options gets too long if you're not
>> careful.
>
> Will do.
>>
>> In memReporter.hpp
>>
>> A short comment before each class what they are for and how you would
>> get to this code would be nice. I think they correspond to NMT
>> settings (summary vs. detail). Mem*DiffReporter reports the
>> difference between the current memory tracked and a previous snapshot
>> it appears.
> Will do.
>>
>>
>> In memReporter.cpp
>>
>> Lines 302-311, you could have two functions that does this same
>> calculation for these values so that it doesn't get broken. The same
>> calculation appears 61 and 64.
>>
>> If you use size_t can you avoid eagerly scaling the amounts?
>> amount_in_current_scale appears 66 times which is a lot. Can you
>> only call the scaling when you print the amounts?
> I think that is what I did. All calculations are done in byte scale,
> only converts to current scale when checks amount > 0 in current
> scale, and print the number.
>
>> In MemTracker.hpp
>>
>> Line 109, I think you can assert that the JVM is single threaded.
>>
> What's the reliable method to check JVM single thread mode? I tried in
> early NMT implementation, but it was not reliable.
>
> Thanks,
>
> -Zhengyu
>
>> That's as far as I got today. This looks good!
>>
>> Coleen
>>
>> On 5/22/14, 3:19 PM, Zhengyu Gu wrote:
>>> This is significant rework of native memory tracking introduced in
>>> earlier releases.
>>>
>>> The goal of this enhancement is to improve scalability, from both
>>> tracking memory and CPU usage perspectives, so it can scale well
>>> with increased memory allocation in large applications.
>>>
>>> The enhancement is mainly focused on malloc memory tracking, whose
>>> activities are several magnitude higher than virtual memory, and was
>>> the main bottleneck in early implementation.
>>>
>>> Instead of using book keeping records for tracking malloc
>>> activities, new implementation co-locates tracking data along side
>>> with user data by using a prefixed header. The header size is 8
>>> bytes on 32-bit systems and 16 bytes on 64-bit systems, which ensure
>>> that user data also align properly.
>>>
>>> Virtual memory tracking still uses book keeping records, and
>>> ThreadCritical lock is always acquired to alter the records and
>>> related data structures.
>>>
>>> Summary tracking data is maintained in static data structures, via
>>> atomic operations. Malloc detail tracking call stacks are maintained
>>> in a lock free hashtable.
>>>
>>> The key improvements:
>>> 1. Up-to-date tracking report.
>>> 2. Detail tracking now shows multiple call frames. Number of
>>> frames is compilation time decision, currently default to 4.
>>> 3. Malloc tracking is lock free.
>>> 4. Tracking summary is reported in hs_err file when native memory
>>> tracking is enabled.
>>> 5. Query is faster, uses little memory and need a very little
>>> process.
>>>
>>> The drawback is that, malloc tracking header is always needed if
>>> native memory tracking has ever been enabled, even after tracking is
>>> shutdown.
>>>
>>> Impacts:
>>> The most noticeable impact for JVM developers, is that Arena now
>>> also take memory type as constructor parameter, besides the new
>>> operators.
>>> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode)
>>> Arena(mtCode)
>>>
>>> The webrev shows modification of about 60 files, but most of them
>>> are due to tracking API changes, mainly due to tracking stack, now,
>>> is an object, vs. a single pc.
>>>
>>> The most important files for this implementations are:
>>>
>>> memTracker.hpp/cpp
>>> mallocTracker.hpp/cpp and mallocTracker.inline.hpp
>>> virtualMemoryTracker.hpp/cpp
>>> mallocSiteTable.hpp/cpp
>>>
>>> allocationSite.hpp
>>> nativeCallStack.hpp/cpp
>>> linkedlist.hpp
>>>
>>>
>>> Tests:
>>> - JPRT
>>> - NMT test suite
>>> - vm.quick.testlist
>>> - Kitchensink stability test for 16+ days
>>> - FMW
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028541
>>> Webrev: http://cr.openjdk.java.net/~zgu/8028541/webrev.00/
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>
>
From erik.joelsson at oracle.com Fri Jun 13 06:56:44 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Jun 2014 08:56:44 +0200
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <539A1939.80103@oracle.com>
References: <53979E97.1040609@oracle.com>
<5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com>
<539A1939.80103@oracle.com>
Message-ID: <539AA0AC.6090202@oracle.com>
Looks fine to me.
/Erik
On 2014-06-12 23:18, Mikael Vidstedt wrote:
>
> I have now verified that the changes work just fine for the platforms
> we build and test - both from the top level and when building hotspot
> only. Taking suggestions on other tests to perform. And it would be
> great if somebody could test the changes on on aix/ppc.
>
> So, kindly asking for "real"/final reviews of the changes:
>
> top:
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
> hotspot:
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>
> Cheers,
> Mikael
>
> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>
>> David,
>>
>> Thanks for the feedback. Essentially the logic in the
>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>> two different use cases:
>>
>> 1. ARCH being set by the JDK build system to the value of
>> OPENJDK_TARGET_CPU_ARCH, or
>> 2. no ARCH being set, in which case it needs to be populated -
>> typically from uname
>>
>> Since Solaris and bsd both override ARCH they do not care about
>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>
>> Linux/x86 is where most of the difference (and confusion) is, but I
>> think aix/ppc64 will also change slightly since the ARCH value will
>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>> cannot verify that they actually work. cc:ing the ppc-aix list in the
>> hope that somebody can help out with that.
>>
>>
>> Summing it up, I have the following two webrevs:
>>
>> top:
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>> hotspot:
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>
>> With these changes I can build the normal platforms, but more
>> verification is needed - esp. building hotspot only. Meanwhile
>> feedback is much appreciated!
>>
>> Cheers,
>> Mikael
>>
>> On 2014-06-10 19:45, David Holmes wrote:
>>> Hi Mikael,
>>>
>>> This seems a reasonable proposal to me. We have an over-abundance of
>>> "arch" variables and values, so reducing that is a good aim.
>>>
>>> As you note the main flow-on effect here is that the hotspot
>>> makefiles have to be updated for the cases where
>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so that
>>> it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think only
>>> x86 has that issue.
>>>
>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc both
>>> internally and in the build artifacts and bundles!
>>>
>>> Cheers,
>>> David
>>>
>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>
>>>> All,
>>>>
>>>> I need some feedback and comments on the below fix:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>
>>>> Background:
>>>>
>>>> When configuring the hotspot build the build system sets up the ARCH
>>>> variable to reflect the target cpu. Currently the value is initialized
>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>> name. For
>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The
>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>> gradually removed in favor of the other variables.
>>>>
>>>> Discussion:
>>>>
>>>> The two candidate variables to base ARCH on are as far as I can tell
>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>> ignored on
>>>> solaris and bsd - it's overridden at the top of the respective
>>>> make/<os>/makefiles/defs.make files.
>>>>
>>>> Before I go too far with this though I'd like to get some feedback on
>>>> whether or not this is the right approach and what the exact value
>>>> should be. Depending on the outcome of that the Hotspot build
>>>> system may
>>>> have to be updated for some platforms to support the new value(s).
>>>>
>>>> Thanks,
>>>> Mikael
>>>>
>>
>
From roland.westrelin at oracle.com Fri Jun 13 07:26:19 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 13 Jun 2014 09:26:19 +0200
Subject: [8u20] 8032410: compiler/uncommontrap/TestStackBangRbp.java times
out on Solaris-Sparc V9
In-Reply-To: <5399CCCC.1060906@oracle.com>
References: <86457131-4CF8-4A43-9545-6B4A9DF62C32@oracle.com>
<5399CCCC.1060906@oracle.com>
Message-ID: <B9D03275-7D13-4F57-8959-9AC7D7DD103C@oracle.com>
Thank you, Vladimir.
Roland.
On Jun 12, 2014, at 5:52 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> Good.
>
> Vladimir
>
> On 6/12/14 5:36 AM, Roland Westrelin wrote:
>> 8u20 backport request. The change was pushed to jdk9 almost 2.5 months ago and testing hasn?t shown any problem. I was asked to backport this because it fixes an issue reported by a customer (https://bugs.openjdk.java.net/browse/JDK-8035399)
>>
>> The change applies cleanly to 8u.
>> https://bugs.openjdk.java.net/browse/JDK-8032410
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cfa802bad1d8
>>
>> Roland.
>>
From dan at danny.cz Fri Jun 13 07:55:11 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Fri, 13 Jun 2014 09:55:11 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539A0454.5030906@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
Message-ID: <20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
On Thu, 12 Jun 2014 21:49:40 +0200
Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> Hi,
>
> Which repository is the patch built on? Since it is mostly GC code it
> would be good if it goes in through jdk9/hs-gc.
>
> The changes looks good in the webrev, but the patch did not apply to
> a recent jdk9/hs-gc. Especially the collector policy code has changed
> a lot recently.
>
> I would prefer to look at the changes applied in my workspace before
> approving it, so if you could update to a recent hs-gc it would be
> great.
I have refreshed the patch for the hs-gc repository, please see
http://fedora.danny.cz/openjdk/size_t-1/webrev/
Thanks,
Dan
> Thanks!
> /Jesper
>
> Vladimir Kozlov skrev 12/6/14 20:57:
> > Thank you, Dan
> >
> > I think casting is acceptable solution. Someone in GC group should
> > review and sponsor this since you touched GC code mostly.
> >
> > Regards,
> > Vladimir
> >
> > On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >> Hello,
> >>
> >> this the last and largest part of my changes required on s390
> >> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2 functions
> >> are implemented using templates and require both arguments to be
> >> of the same type. This is a problem when one parameter is of
> >> size_t type and the second of uintx type and the platform has
> >> size_t defined as eg. unsigned long as on s390 (32-bit).
> >>
> >> As a solution [1] I chose to typecast the smaller type (uintx) to
> >> size_t which is of same or larger size.
> >>
> >> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>
> >> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
> >> covered by Red Hat's CLA for my contributions.
> >>
> >>
> >> With regards
> >>
> >> Dan
> >>
From nils.eliasson at oracle.com Fri Jun 13 08:28:40 2014
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 13 Jun 2014 10:28:40 +0200
Subject: [8u20] RFR(XXS): JDK-8040244
compiler/whitebox/IsMethodCompilableTest.java fails
In-Reply-To: <5399CDBF.6010804@oracle.com>
References: <5399642A.5060707@oracle.com> <5399CDBF.6010804@oracle.com>
Message-ID: <539AB638.9080809@oracle.com>
Thanks Vladimir!
//N
On 2014-06-12 17:56, Vladimir Kozlov wrote:
> Looks good.
>
> Vladimir
>
> On 6/12/14 1:26 AM, Nils Eliasson wrote:
>> Hi,
>>
>> I would like to request a 8u20 backport of JDK-8040244.
>>
>> The change was pushed to jdk 9 yesterday and has passed one nightly
>> without problems. The change applies to 8u without
>> conflicts.
>>
>> Master bug: https://bugs.openjdk.java.net/browse/JDK-8040244
>> Webrev: http://cr.openjdk.java.net/~neliasso/8040244/webrev.01/
>> Changeset:
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/93a279538de3
>>
>> Thanks,
>> Nils
From bengt.rutisson at oracle.com Fri Jun 13 12:10:53 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 13 Jun 2014 14:10:53 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com>
<539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
Message-ID: <539AEA4D.8020204@oracle.com>
Hi Dan,
I haven't looked in detail at this fix, but I have a question. How do we
make sure that we don't introduce new calls to MAX2() that mix size_t
and uintx? It seems like this fix is a bit fragile in that sense.
What do you think about introducing specialized MAX2() definitions for
the size_t and uintx combinations. That would avoid the casting in the
code and will be safer going forward.
One detail also. Why does *hum_bytes have to be cast to size_t here? It
is already a size_t*.
http://fedora.danny.cz/openjdk/size_t-1/webrev/src/share/vm/gc_implementation/g1/concurrentMark.cpp.udiff.html
Then a formality comment. I think you have to post the webrev on
cr.openjdk.java.net to get the legal stuff correct.
Thanks,
Bengt
On 2014-06-13 09:55, Dan Hor?k wrote:
> On Thu, 12 Jun 2014 21:49:40 +0200
> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>
>> Hi,
>>
>> Which repository is the patch built on? Since it is mostly GC code it
>> would be good if it goes in through jdk9/hs-gc.
>>
>> The changes looks good in the webrev, but the patch did not apply to
>> a recent jdk9/hs-gc. Especially the collector policy code has changed
>> a lot recently.
>>
>> I would prefer to look at the changes applied in my workspace before
>> approving it, so if you could update to a recent hs-gc it would be
>> great.
> I have refreshed the patch for the hs-gc repository, please see
> http://fedora.danny.cz/openjdk/size_t-1/webrev/
>
>
> Thanks,
>
> Dan
>
>> Thanks!
>> /Jesper
>>
>> Vladimir Kozlov skrev 12/6/14 20:57:
>>> Thank you, Dan
>>>
>>> I think casting is acceptable solution. Someone in GC group should
>>> review and sponsor this since you touched GC code mostly.
>>>
>>> Regards,
>>> Vladimir
>>>
>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>> Hello,
>>>>
>>>> this the last and largest part of my changes required on s390
>>>> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2 functions
>>>> are implemented using templates and require both arguments to be
>>>> of the same type. This is a problem when one parameter is of
>>>> size_t type and the second of uintx type and the platform has
>>>> size_t defined as eg. unsigned long as on s390 (32-bit).
>>>>
>>>> As a solution [1] I chose to typecast the smaller type (uintx) to
>>>> size_t which is of same or larger size.
>>>>
>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>
>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
>>>> covered by Red Hat's CLA for my contributions.
>>>>
>>>>
>>>> With regards
>>>>
>>>> Dan
>>>>
From dan at danny.cz Fri Jun 13 12:55:31 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Fri, 13 Jun 2014 14:55:31 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539AEA4D.8020204@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
<539AEA4D.8020204@oracle.com>
Message-ID: <20140613145531.559f6d943ef097550580a1f6@danny.cz>
On Fri, 13 Jun 2014 14:10:53 +0200
Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>
> Hi Dan,
>
> I haven't looked in detail at this fix, but I have a question. How do
> we make sure that we don't introduce new calls to MAX2() that mix
> size_t and uintx? It seems like this fix is a bit fragile in that
> sense.
Good question and maybe doesn't have an answer. The compiler probably
can't distinguish between size_t and uintx when they are both
"unsigned int" effectively, so it's only s390 (32-bit) I know about
where the problem can be made visible (size_t is "unsigned long").
Ideally someone with a deep knowledge could go through the code and
decide whether the arguments and attributes are using the correct types.
> What do you think about introducing specialized MAX2() definitions
> for the size_t and uintx combinations. That would avoid the casting
> in the code and will be safer going forward.
I think it can't work when both size_t and uintx are "unsigned int". The
newly introduced functions would conflict with the uintx/uintx variant,
so they would have to made specific for case where size_t is not
"unsigned int".
> One detail also. Why does *hum_bytes have to be cast to size_t here?
> It is already a size_t*.
> http://fedora.danny.cz/openjdk/size_t-1/webrev/src/share/vm/gc_implementation/g1/concurrentMark.cpp.udiff.html
ah, it's likely a result from applying the original patch based on the
dev repository onto the hs-gc repository and fixing only newly appeared
problems and skipping a review of the old changes
> Then a formality comment. I think you have to post the webrev on
> cr.openjdk.java.net to get the legal stuff correct.
hm, I've used this procedure (my webrev, then someone privileged takes
it and pushes it) few times in the past and it worked.
Dan
> Thanks,
> Bengt
>
>
> On 2014-06-13 09:55, Dan Hor?k wrote:
> > On Thu, 12 Jun 2014 21:49:40 +0200
> > Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >
> >> Hi,
> >>
> >> Which repository is the patch built on? Since it is mostly GC code
> >> it would be good if it goes in through jdk9/hs-gc.
> >>
> >> The changes looks good in the webrev, but the patch did not apply
> >> to a recent jdk9/hs-gc. Especially the collector policy code has
> >> changed a lot recently.
> >>
> >> I would prefer to look at the changes applied in my workspace
> >> before approving it, so if you could update to a recent hs-gc it
> >> would be great.
> > I have refreshed the patch for the hs-gc repository, please see
> > http://fedora.danny.cz/openjdk/size_t-1/webrev/
> >
> >
> > Thanks,
> >
> > Dan
> >
> >> Thanks!
> >> /Jesper
> >>
> >> Vladimir Kozlov skrev 12/6/14 20:57:
> >>> Thank you, Dan
> >>>
> >>> I think casting is acceptable solution. Someone in GC group should
> >>> review and sponsor this since you touched GC code mostly.
> >>>
> >>> Regards,
> >>> Vladimir
> >>>
> >>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >>>> Hello,
> >>>>
> >>>> this the last and largest part of my changes required on s390
> >>>> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2 functions
> >>>> are implemented using templates and require both arguments to be
> >>>> of the same type. This is a problem when one parameter is of
> >>>> size_t type and the second of uintx type and the platform has
> >>>> size_t defined as eg. unsigned long as on s390 (32-bit).
> >>>>
> >>>> As a solution [1] I chose to typecast the smaller type (uintx) to
> >>>> size_t which is of same or larger size.
> >>>>
> >>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>>>
> >>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
> >>>> covered by Red Hat's CLA for my contributions.
> >>>>
> >>>>
> >>>> With regards
> >>>>
> >>>> Dan
> >>>>
>
From zhengyu.gu at oracle.com Fri Jun 13 14:02:01 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Fri, 13 Jun 2014 10:02:01 -0400
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
In-Reply-To: <539A6556.2070107@oracle.com>
References: <537E4DB2.5020602@oracle.com>
<5398E48E.9020201@oracle.com> <53999E5D.9030403@oracle.com>
<539A6556.2070107@oracle.com>
Message-ID: <539B0459.2040109@oracle.com>
Actually, I am working on this.
It was caught in between outputStream's format check and Mikael's
macros, I need to merge up the repo for this.
There are a lot more instances in memReporter.cpp.
Thanks,
-Zhengyu
On 6/12/2014 10:43 PM, Coleen Phillimore wrote:
>
> Zhengyu,
>
> In nativeCallStack.cpp why do you need
> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC? Can you change the print formats
> to keep gcc from complaining?
>
> Coleen
>
> On 6/12/14, 8:34 AM, Zhengyu Gu wrote:
>> Coleen,
>>
>> Thanks for the review.
>>
>> On 6/11/2014 7:21 PM, Coleen Phillimore wrote:
>>>
>>> Hi Zhengyu,
>>>
>>> I have early feedback but I haven't looked at the new files yet.
>>> Nothing major. I like the new code and I'm glad you could add NMT
>>> tracking to vmError reporting.
>>>
>>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/solaris/vm/os_solaris.cpp.udiff.html
>>>
>>>
>>> + bool os::unsetenv(const char* name) {
>>> + assert(name != NULL, "Null pointer");
>>> + return (::unsetenv(name) == 0);
>>> + }
>>> +
>>>
>>> Can you add this to os_posix.cpp instead? Someday this duplicate
>>> code will be consolidated so it can start in posix even though it's
>>> not posix.
>>>
>> OK. I assume that aix can also use os_posix functions, right?
>>
>>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/windows/vm/os_windows.cpp.udiff.html
>>>
>>>
>>> I thought the original comment was more descriptive. Is it still a
>>> workaround?
>>>
>> I think we still need this workaround. Auto-merge overwrote
>> Christian's comment, I will restore.
>>
>>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/share/vm/runtime/arguments.cpp.html
>>>
>>>
>>> Can you factor lines 3596-3623 into a function like
>>> verify_nmt_flag? Is it that you already know what nmt level is used
>>> from the launcher and are just checking consistency and initializing
>>> here? These cascading if() code checking options gets too long if
>>> you're not careful.
>>
>> Will do.
>>>
>>> In memReporter.hpp
>>>
>>> A short comment before each class what they are for and how you
>>> would get to this code would be nice. I think they correspond to
>>> NMT settings (summary vs. detail). Mem*DiffReporter reports the
>>> difference between the current memory tracked and a previous
>>> snapshot it appears.
>> Will do.
>>>
>>>
>>> In memReporter.cpp
>>>
>>> Lines 302-311, you could have two functions that does this same
>>> calculation for these values so that it doesn't get broken. The
>>> same calculation appears 61 and 64.
>>>
>>> If you use size_t can you avoid eagerly scaling the amounts?
>>> amount_in_current_scale appears 66 times which is a lot. Can you
>>> only call the scaling when you print the amounts?
>> I think that is what I did. All calculations are done in byte scale,
>> only converts to current scale when checks amount > 0 in current
>> scale, and print the number.
>>
>>> In MemTracker.hpp
>>>
>>> Line 109, I think you can assert that the JVM is single threaded.
>>>
>> What's the reliable method to check JVM single thread mode? I tried
>> in early NMT implementation, but it was not reliable.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>> That's as far as I got today. This looks good!
>>>
>>> Coleen
>>>
>>> On 5/22/14, 3:19 PM, Zhengyu Gu wrote:
>>>> This is significant rework of native memory tracking introduced in
>>>> earlier releases.
>>>>
>>>> The goal of this enhancement is to improve scalability, from both
>>>> tracking memory and CPU usage perspectives, so it can scale well
>>>> with increased memory allocation in large applications.
>>>>
>>>> The enhancement is mainly focused on malloc memory tracking, whose
>>>> activities are several magnitude higher than virtual memory, and
>>>> was the main bottleneck in early implementation.
>>>>
>>>> Instead of using book keeping records for tracking malloc
>>>> activities, new implementation co-locates tracking data along side
>>>> with user data by using a prefixed header. The header size is 8
>>>> bytes on 32-bit systems and 16 bytes on 64-bit systems, which
>>>> ensure that user data also align properly.
>>>>
>>>> Virtual memory tracking still uses book keeping records, and
>>>> ThreadCritical lock is always acquired to alter the records and
>>>> related data structures.
>>>>
>>>> Summary tracking data is maintained in static data structures, via
>>>> atomic operations. Malloc detail tracking call stacks are
>>>> maintained in a lock free hashtable.
>>>>
>>>> The key improvements:
>>>> 1. Up-to-date tracking report.
>>>> 2. Detail tracking now shows multiple call frames. Number of
>>>> frames is compilation time decision, currently default to 4.
>>>> 3. Malloc tracking is lock free.
>>>> 4. Tracking summary is reported in hs_err file when native memory
>>>> tracking is enabled.
>>>> 5. Query is faster, uses little memory and need a very little
>>>> process.
>>>>
>>>> The drawback is that, malloc tracking header is always needed if
>>>> native memory tracking has ever been enabled, even after tracking
>>>> is shutdown.
>>>>
>>>> Impacts:
>>>> The most noticeable impact for JVM developers, is that Arena now
>>>> also take memory type as constructor parameter, besides the new
>>>> operators.
>>>> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode)
>>>> Arena(mtCode)
>>>>
>>>> The webrev shows modification of about 60 files, but most of them
>>>> are due to tracking API changes, mainly due to tracking stack, now,
>>>> is an object, vs. a single pc.
>>>>
>>>> The most important files for this implementations are:
>>>>
>>>> memTracker.hpp/cpp
>>>> mallocTracker.hpp/cpp and mallocTracker.inline.hpp
>>>> virtualMemoryTracker.hpp/cpp
>>>> mallocSiteTable.hpp/cpp
>>>>
>>>> allocationSite.hpp
>>>> nativeCallStack.hpp/cpp
>>>> linkedlist.hpp
>>>>
>>>>
>>>> Tests:
>>>> - JPRT
>>>> - NMT test suite
>>>> - vm.quick.testlist
>>>> - Kitchensink stability test for 16+ days
>>>> - FMW
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028541
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8028541/webrev.00/
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>
>>
>
From vladimir.kozlov at oracle.com Fri Jun 13 15:50:37 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 13 Jun 2014 08:50:37 -0700
Subject: [8u20] RFR (XS) 8046516: Segmentation fault in JVM (easily
reproducible)
Message-ID: <539B1DCD.4030108@oracle.com>
8u20 backport request. The fix was pushed into jdk9 yesterday and nightly testing shows no related problems.
Changes from jdk9 applied to 8u without conflicts.
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/455be7c3df86
http://cr.openjdk.java.net/~kvn/8046516/webrev/
https://bugs.openjdk.java.net/browse/JDK-8046516
Thanks,
Vladimir
From christian.thalinger at oracle.com Fri Jun 13 16:52:30 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 13 Jun 2014 09:52:30 -0700
Subject: [8u20] RFR (XS) 8046516: Segmentation fault in JVM (easily
reproducible)
In-Reply-To: <539B1DCD.4030108@oracle.com>
References: <539B1DCD.4030108@oracle.com>
Message-ID: <B51512E8-0AEE-4E88-84DB-1A76E3E10970@oracle.com>
Good.
On Jun 13, 2014, at 8:50 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 8u20 backport request. The fix was pushed into jdk9 yesterday and nightly testing shows no related problems.
>
> Changes from jdk9 applied to 8u without conflicts.
>
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/455be7c3df86
> http://cr.openjdk.java.net/~kvn/8046516/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8046516
>
> Thanks,
> Vladimir
From vladimir.kozlov at oracle.com Fri Jun 13 17:07:27 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 13 Jun 2014 10:07:27 -0700
Subject: [8u20] RFR (XS) 8046516: Segmentation fault in JVM (easily
reproducible)
In-Reply-To: <B51512E8-0AEE-4E88-84DB-1A76E3E10970@oracle.com>
References: <539B1DCD.4030108@oracle.com>
<B51512E8-0AEE-4E88-84DB-1A76E3E10970@oracle.com>
Message-ID: <539B2FCF.6040207@oracle.com>
Thank you, Christian
Vladimir
On 6/13/14 9:52 AM, Christian Thalinger wrote:
> Good.
>
> On Jun 13, 2014, at 8:50 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> 8u20 backport request. The fix was pushed into jdk9 yesterday and nightly testing shows no related problems.
>>
>> Changes from jdk9 applied to 8u without conflicts.
>>
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/455be7c3df86
>> http://cr.openjdk.java.net/~kvn/8046516/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8046516
>>
>> Thanks,
>> Vladimir
>
From christian.tornqvist at oracle.com Fri Jun 13 18:09:08 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Fri, 13 Jun 2014 14:09:08 -0400
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
In-Reply-To: <537E4DB2.5020602@oracle.com>
References: <537E4DB2.5020602@oracle.com>
Message-ID: <009b01cf8732$9290a020$b7b1e060$@oracle.com>
Hi Zhengyu,
I've only covered parts of this change so far, but here is some of my early feedback:
src/os/linux/vm/os_linux.cpp
* Line 226 & 227, incorrect indentation
src/os/posix/vm/os_posix.cpp
* Line 80 (and other): should not have spaces between variable and ++/--
src/os/solaris/vm/os_solaris.cpp
* Line 566 & 567, incorrect indentation
src/os/windows/vm/os_windows.cpp
* Line 162 & 163, incorrect indentation
src/os/windows/vm/perfMemory_windows.cpp
* Line 1844, can you move the remove_file_mapping call outside the if statement to get rid of the else statement?
src/share/vm/memory/allocation.inline.hpp
* Incorrect indentation on many lines
src/share/vm/services/memBaseline.cpp
* Incorrect indentation on many lines
* Line 92, should not have spaces between variable and ++/--
* Line 136, Split the assert into two asserts
* aggregate_virtual_memory_allocation_sites() returns a bool but you never check the return value?
* Why don't you merge malloc_sites (and the virtual equivalents) with malloc_sites_to_size_order() and malloc_sites_to_site_order(). The code is 95% the same and you should be able to easily remove the duplicated code here.
src/share/vm/services/memBaseline.hpp
* Line 165, Split the assert into two asserts
Thanks,
Christian
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Zhengyu Gu
Sent: Thursday, May 22, 2014 3:19 PM
To: hotspot-dev at openjdk.java.net
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
This is significant rework of native memory tracking introduced in earlier releases.
The goal of this enhancement is to improve scalability, from both tracking memory and CPU usage perspectives, so it can scale well with increased memory allocation in large applications.
The enhancement is mainly focused on malloc memory tracking, whose activities are several magnitude higher than virtual memory, and was the main bottleneck in early implementation.
Instead of using book keeping records for tracking malloc activities, new implementation co-locates tracking data along side with user data by using a prefixed header. The header size is 8 bytes on 32-bit systems and 16 bytes on 64-bit systems, which ensure that user data also align properly.
Virtual memory tracking still uses book keeping records, and ThreadCritical lock is always acquired to alter the records and related data structures.
Summary tracking data is maintained in static data structures, via atomic operations. Malloc detail tracking call stacks are maintained in a lock free hashtable.
The key improvements:
1. Up-to-date tracking report.
2. Detail tracking now shows multiple call frames. Number of frames is compilation time decision, currently default to 4.
3. Malloc tracking is lock free.
4. Tracking summary is reported in hs_err file when native memory tracking is enabled.
5. Query is faster, uses little memory and need a very little process.
The drawback is that, malloc tracking header is always needed if native memory tracking has ever been enabled, even after tracking is shutdown.
Impacts:
The most noticeable impact for JVM developers, is that Arena now also take memory type as constructor parameter, besides the new operators.
Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode)
Arena(mtCode)
The webrev shows modification of about 60 files, but most of them are due to tracking API changes, mainly due to tracking stack, now, is an object, vs. a single pc.
The most important files for this implementations are:
memTracker.hpp/cpp
mallocTracker.hpp/cpp and mallocTracker.inline.hpp virtualMemoryTracker.hpp/cpp mallocSiteTable.hpp/cpp
allocationSite.hpp
nativeCallStack.hpp/cpp
linkedlist.hpp
Tests:
- JPRT
- NMT test suite
- vm.quick.testlist
- Kitchensink stability test for 16+ days
- FMW
Bug: https://bugs.openjdk.java.net/browse/JDK-8028541
Webrev: http://cr.openjdk.java.net/~zgu/8028541/webrev.00/
Thanks,
-Zhengyu
From mike.duigou at oracle.com Fri Jun 13 19:43:37 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Jun 2014 12:43:37 -0700
Subject: RFR: 8046765 : (s) makefiles should use parameterized $(CP) and $(MV)
rather than explicit commands
Message-ID: <839864EB-04E0-45B0-8D31-25714E84E1A7@oracle.com>
Hello all;
This is a small changeset to the hotspot makefiles to have them use expansions of the $(CP) and $(MV) variables rather than explicit commands for all operations involving files in the deliverables. This changes is needed by static code analysis software which provides replacement cp and mv commands that track error reports in executables back to the source from which they are generated.
jbsbug: https://bugs.openjdk.java.net/browse/JDK-8046765
webrev: http://cr.openjdk.java.net/~mduigou/JDK-8046765/0/webrev/
I've checked to make sure that patch doesn't change the build output on linux x64 and am currently checking on other platforms.
It is probably easier to review this change by looking at the patch than by looking at the file diffs.
Mike
From vladimir.kozlov at oracle.com Fri Jun 13 19:56:18 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 13 Jun 2014 12:56:18 -0700
Subject: RFR: 8046765 : (s) makefiles should use parameterized $(CP) and
$(MV) rather than explicit commands
In-Reply-To: <839864EB-04E0-45B0-8D31-25714E84E1A7@oracle.com>
References: <839864EB-04E0-45B0-8D31-25714E84E1A7@oracle.com>
Message-ID: <539B5762.4010904@oracle.com>
Looks fine to me.
Thanks,
Vladimir
On 6/13/14 12:43 PM, Mike Duigou wrote:
> Hello all;
>
> This is a small changeset to the hotspot makefiles to have them use expansions of the $(CP) and $(MV) variables rather than explicit commands for all operations involving files in the deliverables. This changes is needed by static code analysis software which provides replacement cp and mv commands that track error reports in executables back to the source from which they are generated.
>
> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8046765
> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8046765/0/webrev/
>
> I've checked to make sure that patch doesn't change the build output on linux x64 and am currently checking on other platforms.
>
> It is probably easier to review this change by looking at the patch than by looking at the file diffs.
>
> Mike
>
From david.dehaven at oracle.com Sat Jun 14 01:09:38 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 13 Jun 2014 18:09:38 -0700
Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
In-Reply-To: <F56C5565-69B9-4833-9A7C-D6B0FFC92ED5@oracle.com>
References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
<173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
<539905F1.7060509@oracle.com>
<F56C5565-69B9-4833-9A7C-D6B0FFC92ED5@oracle.com>
Message-ID: <F87B4C04-95CE-4FB5-9C85-F1C5FB5218C4@oracle.com>
Updated. I kicked off a JPRT -bo run to be sure it doesn't break something else.
http://cr.openjdk.java.net/~ddehaven/8043340/v4/
Only change from previous is in make/bsd/makefiles/saproc.make, I added SA_SYSROOT_FLAGS which is set to SYSROOT_CFLAGS. I didn't want to add SYSROOT_CFLAGS to the compile command in case $(CC) expands to something that includes the same args on non-Mac platforms, this seems safer.
-DrD-
>
> Yes, I was going for convenience and minimizing disturbance. I'll change how the flags are passed.
>
> If SDKROOT is unset then the paths point at the existing hard-coded paths in /System/Library/Frameworks, all SDKROOT does is prepend the SDK path and it's only set under certain conditions. JPRT has been perfectly happy with this change so far.
>
> Note that this ugliness can go away when we remove the dependencies on the JavaNativeFoundation and JavaRuntimeSupport frameworks.
>
> -DrD-
>
>> Hi David,
>>
>> In saproc.make:
>>
>> Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you are adding is nothing to do with the ARCH setting. If none of the existing variables are suitable perhaps just add SA_CFLAGS?
>>
>> If SDKROOT is not set is the path one that would normally exist? In particular does it exist on all our JPRT clients?
>>
>> Thanks,
>> David H.
>>
>> On 12/06/2014 6:06 AM, David DeHaven wrote:
>>>
>>> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this?
>>>
>>> The hotspot specific changes are here:
>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/
>>>
>>> Also, is there a problem if I push these through jdk9/build instead of going through hotspot?
>>>
>>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results.
>>>
>>> -DrD-
>>>
>>>> From: David DeHaven <david.dehaven at oracle.com>
>>>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
>>>> Date: June 4, 2014 16:01:29 PDT
>>>> To: build-dev build-dev <build-dev at openjdk.java.net>
>>>>
>>>>
>>>> Next (hopefully last??) update:
>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>>>>
>>>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>>>>
>>>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>>>>
>>>>
>>>> These comments in flags.m4 are a bit misleading and not really true:
>>>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
>>>> # FIXME: clean this up, and/or move it elsewhere.
>>>>
>>>> So, I removed them...
>>>>
>>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>>>>
>>>>
>>>>
>>>> Testing:
>>>>
>>>> I now have two system configurations I'm testing with:
>>>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
>>>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>>>>
>>>> System 1 tests:
>>>> $ sudo xcode-select -switch /Applications/Xcode.app
>>>> $ make clean; sh ./configure; make images
>>>> ...
>>>> 00:09:17 TOTAL
>>>> -------------------------
>>>> Finished building Java(TM) for target 'images'
>>>>
>>>>
>>>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
>>>> ...
>>>> 00:13:37 TOTAL
>>>> -------------------------
>>>> Finished building Java(TM) for target 'images'
>>>>
>>>> (Note that building with Xcode 5/clang is faster...)
>>>>
>>>>
>>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>>>> $ make clean; sh ./configure; make images
>>>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
>>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
>>>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>>>>
>>>>
>>>> $ make clean; sh ./configure --with-toolchain-type=clang; make images
>>>> ...
>>>> 00:10:54 TOTAL
>>>> -------------------------
>>>> Finished building Java(TM) for target 'images'
>>>>
>>>>
>>>> System 2 tests:
>>>> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>>> ...
>>>> 00:20:26 TOTAL
>>>> -------------------------
>>>> Finished building OpenJDK for target 'images'
>>>>
>>>>
>>>> Closed JDK (images only, deploy/install expected to fail)
>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>>> ...
>>>> 00:10:05 TOTAL
>>>> -------------------------
>>>> Finished building Java(TM) for target 'images'
>>>>
>>>> -DrD-
>>>>
>>>
>
From david.holmes at oracle.com Mon Jun 16 06:31:29 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jun 2014 16:31:29 +1000
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140613145531.559f6d943ef097550580a1f6@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com>
<539A0454.5030906@oracle.com> <20140613095511.5fae7c4b483bb65f073e5628@danny.cz> <539AEA4D.8020204@oracle.com>
<20140613145531.559f6d943ef097550580a1f6@danny.cz>
Message-ID: <539E8F41.6070001@oracle.com>
On 13/06/2014 10:55 PM, Dan Hor?k wrote:
> On Fri, 13 Jun 2014 14:10:53 +0200
> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>> Then a formality comment. I think you have to post the webrev on
>> cr.openjdk.java.net to get the legal stuff correct.
>
> hm, I've used this procedure (my webrev, then someone privileged takes
> it and pushes it) few times in the past and it worked.
We've been advised that all contributions have to come in via OpenJDK
infrastructure - either a webrev on cr.openjdk.java.net or as
attachments to mailing list mails.
David
-----
>
> Dan
>
>
>> Thanks,
>> Bengt
>>
>>
>> On 2014-06-13 09:55, Dan Hor?k wrote:
>>> On Thu, 12 Jun 2014 21:49:40 +0200
>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Which repository is the patch built on? Since it is mostly GC code
>>>> it would be good if it goes in through jdk9/hs-gc.
>>>>
>>>> The changes looks good in the webrev, but the patch did not apply
>>>> to a recent jdk9/hs-gc. Especially the collector policy code has
>>>> changed a lot recently.
>>>>
>>>> I would prefer to look at the changes applied in my workspace
>>>> before approving it, so if you could update to a recent hs-gc it
>>>> would be great.
>>> I have refreshed the patch for the hs-gc repository, please see
>>> http://fedora.danny.cz/openjdk/size_t-1/webrev/
>>>
>>>
>>> Thanks,
>>>
>>> Dan
>>>
>>>> Thanks!
>>>> /Jesper
>>>>
>>>> Vladimir Kozlov skrev 12/6/14 20:57:
>>>>> Thank you, Dan
>>>>>
>>>>> I think casting is acceptable solution. Someone in GC group should
>>>>> review and sponsor this since you touched GC code mostly.
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>>>> Hello,
>>>>>>
>>>>>> this the last and largest part of my changes required on s390
>>>>>> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2 functions
>>>>>> are implemented using templates and require both arguments to be
>>>>>> of the same type. This is a problem when one parameter is of
>>>>>> size_t type and the second of uintx type and the platform has
>>>>>> size_t defined as eg. unsigned long as on s390 (32-bit).
>>>>>>
>>>>>> As a solution [1] I chose to typecast the smaller type (uintx) to
>>>>>> size_t which is of same or larger size.
>>>>>>
>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>>>
>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
>>>>>> covered by Red Hat's CLA for my contributions.
>>>>>>
>>>>>>
>>>>>> With regards
>>>>>>
>>>>>> Dan
>>>>>>
>>
From david.holmes at oracle.com Mon Jun 16 06:45:08 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jun 2014 16:45:08 +1000
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539A1477.4030406@oracle.com>
References: <5398C681.70209@oracle.com> <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com> <5399CE05.2060806@oracle.com> <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com>
Message-ID: <539E9274.9070300@oracle.com>
On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
>
> Thank you, John! Christian suggested I take out ConstantPool::lock()
> and while doing so I discovered I was still using the unsafe
> ConstantPool::unresolved_klass_at() call. So I replaced these with
> ConstantPool::klass_name_at() which is safe.
>
> Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking
> the metaspace_lock() must not check for safepoints.
Just to be paranoid ... so all user's of this lock elide the safepoint
check, and no use of this lock can encounter a safepoint within the
locked region?
David
-----
> I make Chris's changes and fixed these problems and retested. Most
> files are unchanged, but here is the updated webrev.
>
> I didn't mention before that this change saves 152 bytes per class.
>
> http://cr.openjdk.java.net/~coleenp/8026977_2/
>
> Thanks!
> Coleen
>
> On 6/12/14, 12:57 PM, John Rose wrote:
>> Reviewed. This is a good change. The code is much cleaner. Thanks.
>> ? John
>>
>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
>> <coleen.phillimore at oracle.com> wrote:
>>
>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>> +Mutex* ConstantPool::lock() {
>>>> + // Use the lock from the metaspace in the rare instance we need
>>>> to lock the entries
>>>> + // in this cpool or its associated cache. Only used for setting
>>>> invokedynamic cpCache
>>>> + // entry.
>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>> +}
>>>>
>>>> I?d rather see this method removed completely and use the metaspace
>>>> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
>>>> Otherwise it's confusing.
>>> Ok, I can change that.
>>>
>>> Coleen
>>>
>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
>>>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
>>>> wrote:
>>>>
>>>>> Summary: Write klass and resolved_references constant pool fields
>>>>> lock free.
>>>>>
>>>>> The constant pool values that can change were already read lock
>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
>>>>> other values that can change were moved to the resolved_references
>>>>> array, which is initialized to null. Non-null is the resolved
>>>>> value. With a couple uses of CAS, we can eliminate the need for
>>>>> the constant pool lock for the constant pool changes. Error
>>>>> handling also changes the tag but saving the resolution exception
>>>>> was done under the SystemDictionary_lock, so only the tag change
>>>>> needs a CAS.
>>>>>
>>>>> The only remaining use for the constant pool lock is updating the
>>>>> cpCache for invokedynamic. There are 4 fields that need to be
>>>>> consistent. These now use the metaspace lock associated with the
>>>>> class loader that owns the constant pool, which is only held
>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
>>>>> which show no regression.
>>>>>
>>>>> Other testing - ran refworkload on linux x64 with no significant
>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>>
>
From dan at danny.cz Mon Jun 16 07:17:02 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Mon, 16 Jun 2014 09:17:02 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539E8F41.6070001@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
<539AEA4D.8020204@oracle.com>
<20140613145531.559f6d943ef097550580a1f6@danny.cz>
<539E8F41.6070001@oracle.com>
Message-ID: <20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
On Mon, 16 Jun 2014 16:31:29 +1000
David Holmes <david.holmes at oracle.com> wrote:
> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
> > On Fri, 13 Jun 2014 14:10:53 +0200
> > Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> >> Then a formality comment. I think you have to post the webrev on
> >> cr.openjdk.java.net to get the legal stuff correct.
> >
> > hm, I've used this procedure (my webrev, then someone privileged
> > takes it and pushes it) few times in the past and it worked.
>
> We've been advised that all contributions have to come in via OpenJDK
> infrastructure - either a webrev on cr.openjdk.java.net or as
> attachments to mailing list mails.
I understand, but AFAIK cr.openjdk.java.net is accessible only to people
with push access, which I'm not. So the question is will the list
accept 3MB attachment? It is the size of the zipped webrev. Or will a
plain text patch suffice?
Dan
> David
> -----
>
> >
> > Dan
> >
> >
> >> Thanks,
> >> Bengt
> >>
> >>
> >> On 2014-06-13 09:55, Dan Hor?k wrote:
> >>> On Thu, 12 Jun 2014 21:49:40 +0200
> >>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Which repository is the patch built on? Since it is mostly GC
> >>>> code it would be good if it goes in through jdk9/hs-gc.
> >>>>
> >>>> The changes looks good in the webrev, but the patch did not apply
> >>>> to a recent jdk9/hs-gc. Especially the collector policy code has
> >>>> changed a lot recently.
> >>>>
> >>>> I would prefer to look at the changes applied in my workspace
> >>>> before approving it, so if you could update to a recent hs-gc it
> >>>> would be great.
> >>> I have refreshed the patch for the hs-gc repository, please see
> >>> http://fedora.danny.cz/openjdk/size_t-1/webrev/
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Dan
> >>>
> >>>> Thanks!
> >>>> /Jesper
> >>>>
> >>>> Vladimir Kozlov skrev 12/6/14 20:57:
> >>>>> Thank you, Dan
> >>>>>
> >>>>> I think casting is acceptable solution. Someone in GC group
> >>>>> should review and sponsor this since you touched GC code mostly.
> >>>>>
> >>>>> Regards,
> >>>>> Vladimir
> >>>>>
> >>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> this the last and largest part of my changes required on s390
> >>>>>> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2
> >>>>>> functions are implemented using templates and require both
> >>>>>> arguments to be of the same type. This is a problem when one
> >>>>>> parameter is of size_t type and the second of uintx type and
> >>>>>> the platform has size_t defined as eg. unsigned long as on
> >>>>>> s390 (32-bit).
> >>>>>>
> >>>>>> As a solution [1] I chose to typecast the smaller type (uintx)
> >>>>>> to size_t which is of same or larger size.
> >>>>>>
> >>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>>>>>
> >>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
> >>>>>> covered by Red Hat's CLA for my contributions.
> >>>>>>
> >>>>>>
> >>>>>> With regards
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>
From erik.joelsson at oracle.com Mon Jun 16 07:46:43 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 16 Jun 2014 09:46:43 +0200
Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
In-Reply-To: <F87B4C04-95CE-4FB5-9C85-F1C5FB5218C4@oracle.com>
References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com> <173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com> <539905F1.7060509@oracle.com> <F56C5565-69B9-4833-9A7C-D6B0FFC92ED5@oracle.com>
<F87B4C04-95CE-4FB5-9C85-F1C5FB5218C4@oracle.com>
Message-ID: <539EA0E3.4020005@oracle.com>
Looks good to me.
/Erik
On 2014-06-14 03:09, David DeHaven wrote:
> Updated. I kicked off a JPRT -bo run to be sure it doesn't break something else.
>
> http://cr.openjdk.java.net/~ddehaven/8043340/v4/
>
> Only change from previous is in make/bsd/makefiles/saproc.make, I added SA_SYSROOT_FLAGS which is set to SYSROOT_CFLAGS. I didn't want to add SYSROOT_CFLAGS to the compile command in case $(CC) expands to something that includes the same args on non-Mac platforms, this seems safer.
>
> -DrD-
>
>
>> Yes, I was going for convenience and minimizing disturbance. I'll change how the flags are passed.
>>
>> If SDKROOT is unset then the paths point at the existing hard-coded paths in /System/Library/Frameworks, all SDKROOT does is prepend the SDK path and it's only set under certain conditions. JPRT has been perfectly happy with this change so far.
>>
>> Note that this ugliness can go away when we remove the dependencies on the JavaNativeFoundation and JavaRuntimeSupport frameworks.
>>
>> -DrD-
>>
>>> Hi David,
>>>
>>> In saproc.make:
>>>
>>> Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you are adding is nothing to do with the ARCH setting. If none of the existing variables are suitable perhaps just add SA_CFLAGS?
>>>
>>> If SDKROOT is not set is the path one that would normally exist? In particular does it exist on all our JPRT clients?
>>>
>>> Thanks,
>>> David H.
>>>
>>> On 12/06/2014 6:06 AM, David DeHaven wrote:
>>>> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this?
>>>>
>>>> The hotspot specific changes are here:
>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/
>>>>
>>>> Also, is there a problem if I push these through jdk9/build instead of going through hotspot?
>>>>
>>>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results.
>>>>
>>>> -DrD-
>>>>
>>>>> From: David DeHaven <david.dehaven at oracle.com>
>>>>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
>>>>> Date: June 4, 2014 16:01:29 PDT
>>>>> To: build-dev build-dev <build-dev at openjdk.java.net>
>>>>>
>>>>>
>>>>> Next (hopefully last??) update:
>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>>>>>
>>>>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>>>>>
>>>>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>>>>>
>>>>>
>>>>> These comments in flags.m4 are a bit misleading and not really true:
>>>>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
>>>>> # FIXME: clean this up, and/or move it elsewhere.
>>>>>
>>>>> So, I removed them...
>>>>>
>>>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>>>>>
>>>>>
>>>>>
>>>>> Testing:
>>>>>
>>>>> I now have two system configurations I'm testing with:
>>>>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
>>>>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>>>>>
>>>>> System 1 tests:
>>>>> $ sudo xcode-select -switch /Applications/Xcode.app
>>>>> $ make clean; sh ./configure; make images
>>>>> ...
>>>>> 00:09:17 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>>
>>>>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
>>>>> ...
>>>>> 00:13:37 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>> (Note that building with Xcode 5/clang is faster...)
>>>>>
>>>>>
>>>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>>>>> $ make clean; sh ./configure; make images
>>>>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
>>>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
>>>>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>>>>>
>>>>>
>>>>> $ make clean; sh ./configure --with-toolchain-type=clang; make images
>>>>> ...
>>>>> 00:10:54 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>>
>>>>> System 2 tests:
>>>>> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
>>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>>>> ...
>>>>> 00:20:26 TOTAL
>>>>> -------------------------
>>>>> Finished building OpenJDK for target 'images'
>>>>>
>>>>>
>>>>> Closed JDK (images only, deploy/install expected to fail)
>>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>>>> ...
>>>>> 00:10:05 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>> -DrD-
>>>>>
From david.holmes at oracle.com Mon Jun 16 11:15:58 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jun 2014 21:15:58 +1000
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com> <20140613095511.5fae7c4b483bb65f073e5628@danny.cz> <539AEA4D.8020204@oracle.com> <20140613145531.559f6d943ef097550580a1f6@danny.cz> <539E8F41.6070001@oracle.com>
<20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
Message-ID: <539ED1EE.30107@oracle.com>
On 16/06/2014 5:17 PM, Dan Hor?k wrote:
> On Mon, 16 Jun 2014 16:31:29 +1000
> David Holmes <david.holmes at oracle.com> wrote:
>
>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
>>> On Fri, 13 Jun 2014 14:10:53 +0200
>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>>> Then a formality comment. I think you have to post the webrev on
>>>> cr.openjdk.java.net to get the legal stuff correct.
>>>
>>> hm, I've used this procedure (my webrev, then someone privileged
>>> takes it and pushes it) few times in the past and it worked.
>>
>> We've been advised that all contributions have to come in via OpenJDK
>> infrastructure - either a webrev on cr.openjdk.java.net or as
>> attachments to mailing list mails.
>
> I understand, but AFAIK cr.openjdk.java.net is accessible only to people
> with push access, which I'm not.
No you only need Author status, not Committer.
> So the question is will the list
> accept 3MB attachment? It is the size of the zipped webrev. Or will a
> plain text patch suffice?
For large webrevs you may be able to find someone to host it for you on
cr.openjdk. I don't know what limit exists on the mailing list but I'd
hate to see very large patches submitted that way.
Cheers,
David
>
> Dan
>
>> David
>> -----
>>
>>>
>>> Dan
>>>
>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>
>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Which repository is the patch built on? Since it is mostly GC
>>>>>> code it would be good if it goes in through jdk9/hs-gc.
>>>>>>
>>>>>> The changes looks good in the webrev, but the patch did not apply
>>>>>> to a recent jdk9/hs-gc. Especially the collector policy code has
>>>>>> changed a lot recently.
>>>>>>
>>>>>> I would prefer to look at the changes applied in my workspace
>>>>>> before approving it, so if you could update to a recent hs-gc it
>>>>>> would be great.
>>>>> I have refreshed the patch for the hs-gc repository, please see
>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev/
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Dan
>>>>>
>>>>>> Thanks!
>>>>>> /Jesper
>>>>>>
>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
>>>>>>> Thank you, Dan
>>>>>>>
>>>>>>> I think casting is acceptable solution. Someone in GC group
>>>>>>> should review and sponsor this since you touched GC code mostly.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> this the last and largest part of my changes required on s390
>>>>>>>> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2
>>>>>>>> functions are implemented using templates and require both
>>>>>>>> arguments to be of the same type. This is a problem when one
>>>>>>>> parameter is of size_t type and the second of uintx type and
>>>>>>>> the platform has size_t defined as eg. unsigned long as on
>>>>>>>> s390 (32-bit).
>>>>>>>>
>>>>>>>> As a solution [1] I chose to typecast the smaller type (uintx)
>>>>>>>> to size_t which is of same or larger size.
>>>>>>>>
>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>>>>>
>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
>>>>>>>> covered by Red Hat's CLA for my contributions.
>>>>>>>>
>>>>>>>>
>>>>>>>> With regards
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>
From jesper.wilhelmsson at oracle.com Mon Jun 16 14:19:17 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 16 Jun 2014 16:19:17 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539ED1EE.30107@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com> <20140613095511.5fae7c4b483bb65f073e5628@danny.cz> <539AEA4D.8020204@oracle.com> <20140613145531.559f6d943ef097550580a1f6@danny.cz> <539E8F41.6070001@oracle.com> <20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
<539ED1EE.30107@oracle.com>
Message-ID: <539EFCE5.9020108@oracle.com>
Dan,
I can host the webrev. Send me the zipped webrev archive and I'll upload it to
cr.openjdk.
/Jesper
David Holmes skrev 16/6/14 13:15:
> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
>> On Mon, 16 Jun 2014 16:31:29 +1000
>> David Holmes <david.holmes at oracle.com> wrote:
>>
>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
>>>> On Fri, 13 Jun 2014 14:10:53 +0200
>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>>>> Then a formality comment. I think you have to post the webrev on
>>>>> cr.openjdk.java.net to get the legal stuff correct.
>>>>
>>>> hm, I've used this procedure (my webrev, then someone privileged
>>>> takes it and pushes it) few times in the past and it worked.
>>>
>>> We've been advised that all contributions have to come in via OpenJDK
>>> infrastructure - either a webrev on cr.openjdk.java.net or as
>>> attachments to mailing list mails.
>>
>> I understand, but AFAIK cr.openjdk.java.net is accessible only to people
>> with push access, which I'm not.
>
> No you only need Author status, not Committer.
>
>> So the question is will the list
>> accept 3MB attachment? It is the size of the zipped webrev. Or will a
>> plain text patch suffice?
>
> For large webrevs you may be able to find someone to host it for you on
> cr.openjdk. I don't know what limit exists on the mailing list but I'd hate to
> see very large patches submitted that way.
>
> Cheers,
> David
>
>
>>
>> Dan
>>
>>> David
>>> -----
>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>>
>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Which repository is the patch built on? Since it is mostly GC
>>>>>>> code it would be good if it goes in through jdk9/hs-gc.
>>>>>>>
>>>>>>> The changes looks good in the webrev, but the patch did not apply
>>>>>>> to a recent jdk9/hs-gc. Especially the collector policy code has
>>>>>>> changed a lot recently.
>>>>>>>
>>>>>>> I would prefer to look at the changes applied in my workspace
>>>>>>> before approving it, so if you could update to a recent hs-gc it
>>>>>>> would be great.
>>>>>> I have refreshed the patch for the hs-gc repository, please see
>>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev/
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>> Thanks!
>>>>>>> /Jesper
>>>>>>>
>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
>>>>>>>> Thank you, Dan
>>>>>>>>
>>>>>>>> I think casting is acceptable solution. Someone in GC group
>>>>>>>> should review and sponsor this since you touched GC code mostly.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> this the last and largest part of my changes required on s390
>>>>>>>>> (32-bit) to build OpenJDK out of the box. The MIN2/MAX2
>>>>>>>>> functions are implemented using templates and require both
>>>>>>>>> arguments to be of the same type. This is a problem when one
>>>>>>>>> parameter is of size_t type and the second of uintx type and
>>>>>>>>> the platform has size_t defined as eg. unsigned long as on
>>>>>>>>> s390 (32-bit).
>>>>>>>>>
>>>>>>>>> As a solution [1] I chose to typecast the smaller type (uintx)
>>>>>>>>> to size_t which is of same or larger size.
>>>>>>>>>
>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>>>>>>
>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should be
>>>>>>>>> covered by Red Hat's CLA for my contributions.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With regards
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>
From dan at danny.cz Mon Jun 16 14:21:30 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Mon, 16 Jun 2014 16:21:30 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539EFCE5.9020108@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
<539AEA4D.8020204@oracle.com>
<20140613145531.559f6d943ef097550580a1f6@danny.cz>
<539E8F41.6070001@oracle.com>
<20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
<539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com>
Message-ID: <20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
On Mon, 16 Jun 2014 16:19:17 +0200
Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> Dan,
>
> I can host the webrev. Send me the zipped webrev archive and I'll
> upload it to cr.openjdk.
Jesper, thanks a lot, the whole archive is at
http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
Dan
> /Jesper
>
> David Holmes skrev 16/6/14 13:15:
> > On 16/06/2014 5:17 PM, Dan Hor?k wrote:
> >> On Mon, 16 Jun 2014 16:31:29 +1000
> >> David Holmes <david.holmes at oracle.com> wrote:
> >>
> >>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
> >>>> On Fri, 13 Jun 2014 14:10:53 +0200
> >>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> >>>>> Then a formality comment. I think you have to post the webrev on
> >>>>> cr.openjdk.java.net to get the legal stuff correct.
> >>>>
> >>>> hm, I've used this procedure (my webrev, then someone privileged
> >>>> takes it and pushes it) few times in the past and it worked.
> >>>
> >>> We've been advised that all contributions have to come in via
> >>> OpenJDK infrastructure - either a webrev on cr.openjdk.java.net
> >>> or as attachments to mailing list mails.
> >>
> >> I understand, but AFAIK cr.openjdk.java.net is accessible only to
> >> people with push access, which I'm not.
> >
> > No you only need Author status, not Committer.
> >
> >> So the question is will the list
> >> accept 3MB attachment? It is the size of the zipped webrev. Or
> >> will a plain text patch suffice?
> >
> > For large webrevs you may be able to find someone to host it for
> > you on cr.openjdk. I don't know what limit exists on the mailing
> > list but I'd hate to see very large patches submitted that way.
> >
> > Cheers,
> > David
> >
> >
> >>
> >> Dan
> >>
> >>> David
> >>> -----
> >>>
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>> Thanks,
> >>>>> Bengt
> >>>>>
> >>>>>
> >>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
> >>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
> >>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Which repository is the patch built on? Since it is mostly GC
> >>>>>>> code it would be good if it goes in through jdk9/hs-gc.
> >>>>>>>
> >>>>>>> The changes looks good in the webrev, but the patch did not
> >>>>>>> apply to a recent jdk9/hs-gc. Especially the collector policy
> >>>>>>> code has changed a lot recently.
> >>>>>>>
> >>>>>>> I would prefer to look at the changes applied in my workspace
> >>>>>>> before approving it, so if you could update to a recent hs-gc
> >>>>>>> it would be great.
> >>>>>> I have refreshed the patch for the hs-gc repository, please see
> >>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev/
> >>>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>> Thanks!
> >>>>>>> /Jesper
> >>>>>>>
> >>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
> >>>>>>>> Thank you, Dan
> >>>>>>>>
> >>>>>>>> I think casting is acceptable solution. Someone in GC group
> >>>>>>>> should review and sponsor this since you touched GC code
> >>>>>>>> mostly.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Vladimir
> >>>>>>>>
> >>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >>>>>>>>> Hello,
> >>>>>>>>>
> >>>>>>>>> this the last and largest part of my changes required on
> >>>>>>>>> s390 (32-bit) to build OpenJDK out of the box. The MIN2/MAX2
> >>>>>>>>> functions are implemented using templates and require both
> >>>>>>>>> arguments to be of the same type. This is a problem when one
> >>>>>>>>> parameter is of size_t type and the second of uintx type and
> >>>>>>>>> the platform has size_t defined as eg. unsigned long as on
> >>>>>>>>> s390 (32-bit).
> >>>>>>>>>
> >>>>>>>>> As a solution [1] I chose to typecast the smaller type
> >>>>>>>>> (uintx) to size_t which is of same or larger size.
> >>>>>>>>>
> >>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>>>>>>>>
> >>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should
> >>>>>>>>> be covered by Red Hat's CLA for my contributions.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> With regards
> >>>>>>>>>
> >>>>>>>>> Dan
> >>>>>>>>>
> >>>>>
From coleen.phillimore at oracle.com Mon Jun 16 14:38:08 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Jun 2014 10:38:08 -0400
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539E9274.9070300@oracle.com>
References: <5398C681.70209@oracle.com> <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com> <5399CE05.2060806@oracle.com> <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com> <539E9274.9070300@oracle.com>
Message-ID: <539F0150.10508@oracle.com>
On 6/16/14, 2:45 AM, David Holmes wrote:
> On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
>>
>> Thank you, John! Christian suggested I take out ConstantPool::lock()
>> and while doing so I discovered I was still using the unsafe
>> ConstantPool::unresolved_klass_at() call. So I replaced these with
>> ConstantPool::klass_name_at() which is safe.
>>
>> Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking
>> the metaspace_lock() must not check for safepoints.
>
> Just to be paranoid ... so all user's of this lock elide the safepoint
> check, and no use of this lock can encounter a safepoint within the
> locked region?
Yes, to first question and I'm not sure to second. I believe we can
have a metaspace lock and call GC. The reason it's a no-safepoint-check
lock is that it can be taken during GC. Which sounds unnervingly
circular. I'll have to reconstruct why this lock was done this way.
I wish there was a consistency check though. If you take a lock without
checking for safepoint, we should give an assertion if you take the same
lock and check for safepoint. Not sure if there's an easy way to code
it, but I think it would be worth having.
Coleen
>
> David
> -----
>
>> I make Chris's changes and fixed these problems and retested. Most
>> files are unchanged, but here is the updated webrev.
>>
>> I didn't mention before that this change saves 152 bytes per class.
>>
>> http://cr.openjdk.java.net/~coleenp/8026977_2/
>>
>> Thanks!
>> Coleen
>>
>> On 6/12/14, 12:57 PM, John Rose wrote:
>>> Reviewed. This is a good change. The code is much cleaner. Thanks.
>>> ? John
>>>
>>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
>>> <coleen.phillimore at oracle.com> wrote:
>>>
>>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>>> +Mutex* ConstantPool::lock() {
>>>>> + // Use the lock from the metaspace in the rare instance we need
>>>>> to lock the entries
>>>>> + // in this cpool or its associated cache. Only used for setting
>>>>> invokedynamic cpCache
>>>>> + // entry.
>>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>>> +}
>>>>>
>>>>> I?d rather see this method removed completely and use the metaspace
>>>>> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
>>>>> Otherwise it's confusing.
>>>> Ok, I can change that.
>>>>
>>>> Coleen
>>>>
>>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
>>>>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
>>>>> wrote:
>>>>>
>>>>>> Summary: Write klass and resolved_references constant pool fields
>>>>>> lock free.
>>>>>>
>>>>>> The constant pool values that can change were already read lock
>>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
>>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
>>>>>> other values that can change were moved to the resolved_references
>>>>>> array, which is initialized to null. Non-null is the resolved
>>>>>> value. With a couple uses of CAS, we can eliminate the need for
>>>>>> the constant pool lock for the constant pool changes. Error
>>>>>> handling also changes the tag but saving the resolution exception
>>>>>> was done under the SystemDictionary_lock, so only the tag change
>>>>>> needs a CAS.
>>>>>>
>>>>>> The only remaining use for the constant pool lock is updating the
>>>>>> cpCache for invokedynamic. There are 4 fields that need to be
>>>>>> consistent. These now use the metaspace lock associated with the
>>>>>> class loader that owns the constant pool, which is only held
>>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
>>>>>> which show no regression.
>>>>>>
>>>>>> Other testing - ran refworkload on linux x64 with no significant
>>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>>
>>
From daniel.daugherty at oracle.com Mon Jun 16 15:08:53 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 16 Jun 2014 09:08:53 -0600
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539F0150.10508@oracle.com>
References: <5398C681.70209@oracle.com> <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com> <5399CE05.2060806@oracle.com> <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com> <539E9274.9070300@oracle.com>
<539F0150.10508@oracle.com>
Message-ID: <539F0885.4010207@oracle.com>
> If you take a lock without checking for safepoint, we should give
> an assertion if you take the same lock and check for safepoint.
> Not sure if there's an easy way to code it, but I think it would
> be worth having.
Markus G has been working on some code that does this. Not sure
where he is on that adventure.
Dan
On 6/16/14 8:38 AM, Coleen Phillimore wrote:
>
> On 6/16/14, 2:45 AM, David Holmes wrote:
>> On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
>>>
>>> Thank you, John! Christian suggested I take out ConstantPool::lock()
>>> and while doing so I discovered I was still using the unsafe
>>> ConstantPool::unresolved_klass_at() call. So I replaced these with
>>> ConstantPool::klass_name_at() which is safe.
>>>
>>> Also, Sergey Kuksenko's tests exposed a deadlock with this code.
>>> Locking
>>> the metaspace_lock() must not check for safepoints.
>>
>> Just to be paranoid ... so all user's of this lock elide the
>> safepoint check, and no use of this lock can encounter a safepoint
>> within the locked region?
>
> Yes, to first question and I'm not sure to second. I believe we can
> have a metaspace lock and call GC. The reason it's a
> no-safepoint-check lock is that it can be taken during GC. Which
> sounds unnervingly circular. I'll have to reconstruct why this lock
> was done this way.
>
> I wish there was a consistency check though. If you take a lock
> without checking for safepoint, we should give an assertion if you
> take the same lock and check for safepoint. Not sure if there's an
> easy way to code it, but I think it would be worth having.
>
> Coleen
>
>>
>> David
>> -----
>>
>>> I make Chris's changes and fixed these problems and retested. Most
>>> files are unchanged, but here is the updated webrev.
>>>
>>> I didn't mention before that this change saves 152 bytes per class.
>>>
>>> http://cr.openjdk.java.net/~coleenp/8026977_2/
>>>
>>> Thanks!
>>> Coleen
>>>
>>> On 6/12/14, 12:57 PM, John Rose wrote:
>>>> Reviewed. This is a good change. The code is much cleaner. Thanks.
>>>> ? John
>>>>
>>>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>>>> +Mutex* ConstantPool::lock() {
>>>>>> + // Use the lock from the metaspace in the rare instance we need
>>>>>> to lock the entries
>>>>>> + // in this cpool or its associated cache. Only used for setting
>>>>>> invokedynamic cpCache
>>>>>> + // entry.
>>>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>>>> +}
>>>>>>
>>>>>> I?d rather see this method removed completely and use the metaspace
>>>>>> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
>>>>>> Otherwise it's confusing.
>>>>> Ok, I can change that.
>>>>>
>>>>> Coleen
>>>>>
>>>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> Summary: Write klass and resolved_references constant pool fields
>>>>>>> lock free.
>>>>>>>
>>>>>>> The constant pool values that can change were already read lock
>>>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
>>>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
>>>>>>> other values that can change were moved to the resolved_references
>>>>>>> array, which is initialized to null. Non-null is the resolved
>>>>>>> value. With a couple uses of CAS, we can eliminate the need for
>>>>>>> the constant pool lock for the constant pool changes. Error
>>>>>>> handling also changes the tag but saving the resolution exception
>>>>>>> was done under the SystemDictionary_lock, so only the tag change
>>>>>>> needs a CAS.
>>>>>>>
>>>>>>> The only remaining use for the constant pool lock is updating the
>>>>>>> cpCache for invokedynamic. There are 4 fields that need to be
>>>>>>> consistent. These now use the metaspace lock associated with the
>>>>>>> class loader that owns the constant pool, which is only held
>>>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
>>>>>>> which show no regression.
>>>>>>>
>>>>>>> Other testing - ran refworkload on linux x64 with no significant
>>>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>>>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>>>
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>>>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>>
>>>
>
From jesper.wilhelmsson at oracle.com Mon Jun 16 15:26:24 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 16 Jun 2014 17:26:24 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com> <20140613095511.5fae7c4b483bb65f073e5628@danny.cz> <539AEA4D.8020204@oracle.com> <20140613145531.559f6d943ef097550580a1f6@danny.cz> <539E8F41.6070001@oracle.com> <20140616091702.28b895ce918bdf4c58d2506f@danny.cz> <539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com>
<20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
Message-ID: <539F0CA0.3010309@oracle.com>
Hi Dan,
Since you got a comment from Bengt maybe you should fix that issue before I
upload the new webrev.
I looked through the webrev and I have one additional comment. I would prefer if
the changes in arguments.cpp was the other way, casting stuff to uintx instead
of size_t, since we use the result of MAX and MIN to set flags of type uintx.
When I applied the webrev a change in
src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp got in the way of the
patch. The patch still applies but with an offset, so patch complains. If you
build a new webrev with the changes above, also pull down the latest hs-gc to
get the g1CollectedHeap.cpp change.
Thanks!
/Jesper
Dan Hor?k skrev 16/6/14 16:21:
> On Mon, 16 Jun 2014 16:19:17 +0200
> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>
>> Dan,
>>
>> I can host the webrev. Send me the zipped webrev archive and I'll
>> upload it to cr.openjdk.
>
> Jesper, thanks a lot, the whole archive is at
> http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
>
>
> Dan
>
>> /Jesper
>>
>> David Holmes skrev 16/6/14 13:15:
>>> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
>>>> On Mon, 16 Jun 2014 16:31:29 +1000
>>>> David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
>>>>>> On Fri, 13 Jun 2014 14:10:53 +0200
>>>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>>>>>> Then a formality comment. I think you have to post the webrev on
>>>>>>> cr.openjdk.java.net to get the legal stuff correct.
>>>>>>
>>>>>> hm, I've used this procedure (my webrev, then someone privileged
>>>>>> takes it and pushes it) few times in the past and it worked.
>>>>>
>>>>> We've been advised that all contributions have to come in via
>>>>> OpenJDK infrastructure - either a webrev on cr.openjdk.java.net
>>>>> or as attachments to mailing list mails.
>>>>
>>>> I understand, but AFAIK cr.openjdk.java.net is accessible only to
>>>> people with push access, which I'm not.
>>>
>>> No you only need Author status, not Committer.
>>>
>>>> So the question is will the list
>>>> accept 3MB attachment? It is the size of the zipped webrev. Or
>>>> will a plain text patch suffice?
>>>
>>> For large webrevs you may be able to find someone to host it for
>>> you on cr.openjdk. I don't know what limit exists on the mailing
>>> list but I'd hate to see very large patches submitted that way.
>>>
>>> Cheers,
>>> David
>>>
>>>
>>>>
>>>> Dan
>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Bengt
>>>>>>>
>>>>>>>
>>>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
>>>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
>>>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Which repository is the patch built on? Since it is mostly GC
>>>>>>>>> code it would be good if it goes in through jdk9/hs-gc.
>>>>>>>>>
>>>>>>>>> The changes looks good in the webrev, but the patch did not
>>>>>>>>> apply to a recent jdk9/hs-gc. Especially the collector policy
>>>>>>>>> code has changed a lot recently.
>>>>>>>>>
>>>>>>>>> I would prefer to look at the changes applied in my workspace
>>>>>>>>> before approving it, so if you could update to a recent hs-gc
>>>>>>>>> it would be great.
>>>>>>>> I have refreshed the patch for the hs-gc repository, please see
>>>>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev/
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> /Jesper
>>>>>>>>>
>>>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
>>>>>>>>>> Thank you, Dan
>>>>>>>>>>
>>>>>>>>>> I think casting is acceptable solution. Someone in GC group
>>>>>>>>>> should review and sponsor this since you touched GC code
>>>>>>>>>> mostly.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> this the last and largest part of my changes required on
>>>>>>>>>>> s390 (32-bit) to build OpenJDK out of the box. The MIN2/MAX2
>>>>>>>>>>> functions are implemented using templates and require both
>>>>>>>>>>> arguments to be of the same type. This is a problem when one
>>>>>>>>>>> parameter is of size_t type and the second of uintx type and
>>>>>>>>>>> the platform has size_t defined as eg. unsigned long as on
>>>>>>>>>>> s390 (32-bit).
>>>>>>>>>>>
>>>>>>>>>>> As a solution [1] I chose to typecast the smaller type
>>>>>>>>>>> (uintx) to size_t which is of same or larger size.
>>>>>>>>>>>
>>>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>>>>>>>>
>>>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I should
>>>>>>>>>>> be covered by Red Hat's CLA for my contributions.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> With regards
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>
From mark.reinhold at oracle.com Mon Jun 16 15:38:30 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 16 Jun 2014 08:38:30 -0700
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>,
<5399F826.4060409@oracle.com>, <539A0454.5030906@oracle.com>,
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>,
<539AEA4D.8020204@oracle.com>,
<20140613145531.559f6d943ef097550580a1f6@danny.cz>,
<539E8F41.6070001@oracle.com>,
<20140616091702.28b895ce918bdf4c58d2506f@danny.cz>,
<539ED1EE.30107@oracle.com>, <539EFCE5.9020108@oracle.com>,
<20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
Message-ID: <20140616083830.770993@eggemoggin.niobe.net>
2014/6/16 0:21 -0700, dan at danny.cz:
> On Mon, 16 Jun 2014 16:19:17 +0200
> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>> Dan,
>>
>> I can host the webrev. Send me the zipped webrev archive and I'll
>> upload it to cr.openjdk.
>
> Jesper, thanks a lot, the whole archive is at
> http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
Dan -- Please e-mail the archive directly to Jesper. For legal
reasons we can't just copy files from external web sites.
- Mark
From coleen.phillimore at oracle.com Mon Jun 16 15:42:30 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Jun 2014 11:42:30 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
Message-ID: <539F1066.8080302@oracle.com>
Summary: Add classLoader to java/lang/Class instance for fast access
In order to improve performance of Class.getClassLoader() in a way to
allow the compilers to automatically optimize this call, I added the
classLoader to the instance of java/lang/Class. For microbenchmarks,
this results in a 98% improvement, which was expected. For Oracle
internal applications, this results in a 10-12% improvement on
solaris/sparc. The increase in size of java/lang/Class can be offset
by other changes (removing constant pool lock, or removing signers).
See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
associated linked bugs for more details.
open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
There is both hotspot and jdk changes for this change. The hotspot
changes can work without the jdk changes (check for optional field), but
not vice-versa. I'll file another bug (and compatibility request) to
remove JVM_GetClassLoader from hotspot.
Tested with jck lang, vm, api/java_lang tests with/without jdk change,
nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
Thanks,
Coleen
From vladimir.x.ivanov at oracle.com Mon Jun 16 15:52:15 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 16 Jun 2014 19:52:15 +0400
Subject: [8u20] RFR (XXS): 8033626:
assert(ex_map->jvms()->same_calls_as(_exceptions->jvms()))
failed: all collected exceptions must come from the same place
Message-ID: <539F12AF.1060607@oracle.com>
https://bugs.openjdk.java.net/browse/JDK-8033626
http://cr.openjdk.java.net/~vlivanov/8033626/webrev.8u20.00/
This is a request for a backport to 8u20. The fix was integrated into 9
on Tuesday last week and nightly testing hasn't found any issues.
The patch from 9 applies almost cleanly (modulo small unrelated changes
which cause conflict).
Original fix:
http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dd14b24efd49
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-June/014787.html
Best regards,
Vladimir Ivanov
From roland.westrelin at oracle.com Mon Jun 16 15:57:36 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 16 Jun 2014 17:57:36 +0200
Subject: [8u20] RFR (XXS): 8033626:
assert(ex_map->jvms()->same_calls_as(_exceptions->jvms()))
failed: all collected exceptions must come from the same place
In-Reply-To: <539F12AF.1060607@oracle.com>
References: <539F12AF.1060607@oracle.com>
Message-ID: <04BD464C-BFEC-464A-9E4C-B1010CDF0951@oracle.com>
> https://bugs.openjdk.java.net/browse/JDK-8033626
> http://cr.openjdk.java.net/~vlivanov/8033626/webrev.8u20.00/
>
> This is a request for a backport to 8u20. The fix was integrated into 9 on Tuesday last week and nightly testing hasn't found any issues.
>
> The patch from 9 applies almost cleanly (modulo small unrelated changes which cause conflict).
>
> Original fix:
> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dd14b24efd49
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-June/014787.html
That looks good to me.
Roland.
From andrey.x.zakharov at oracle.com Mon Jun 16 15:57:56 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Mon, 16 Jun 2014 19:57:56 +0400
Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file
to JTwork/scratch/sun/hotspot
In-Reply-To: <539727A6.5030307@oracle.com>
References: <536B7CF0.6010508@oracle.com> <536B9E36.6090802@oracle.com>
<536BA28D.7030808@oracle.com> <3503372.bSN5QEX8PY@mgerdin03>
<5371F734.6090809@oracle.com> <537CC81C.6010905@oracle.com>
<537DB9B0.8010200@oracle.com> <537F33CB.5050505@oracle.com>
<5395CBE3.5030502@oracle.com> <539727A6.5030307@oracle.com>
Message-ID: <539F1404.6070307@oracle.com>
Hi, all
So issue is that when tests with WhiteBox API has been invoked with
-Xverify:all it fails with Exception java.lang.NoClassDefFoundError:
sun/hotspot/WhiteBox$WhiteBoxPermission
Solutions that are observed:
1. Copy WhiteBoxPermission with WhiteBox. But
>> Perhaps this is a good time to get rid of ClassFileInstaller altogether?
2. Using bootclasspath to hook pre-built whitebox (due @library
/testlibrary/whitebox) . Some tests has @run main/othervm, some uses
ProcessBuilder.
- main/othervm/bootclasspath adds ${test.src} and ${test.classes}to
options.
- With ProcessBuilder we can just add ${test.classes}
Question here is, can it broke some tests ? While testing this, I found
only https://bugs.openjdk.java.net/browse/JDK-8046231, others looks fine.
3. Make ClassFileInstaller deal with inner classes like that:
diff -r 6ed24aedeef0 -r c01651363ba8
test/testlibrary/ClassFileInstaller.java
--- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 19:02:56
2014 +0400
+++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 18:18:11
2014 +0400
@@ -50,6 +50,16 @@
}
// Create the class file
Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING);
+
+ for (Class<?> cls : Class.forName(arg).getDeclaredClasses()) {
+ //if (!Modifier.isStatic(cls.getModifiers())) {
+ String pathNameSub =
cls.getCanonicalName().replace('.', '/').concat(".class");
+ Path pathSub = Paths.get(pathNameSub);
+ InputStream streamSub =
cl.getResourceAsStream(pathNameSub);
+ Files.copy(streamSub, pathSub,
StandardCopyOption.REPLACE_EXISTING);
+ //}
+ }
+
}
}
}
Works fine for ordinary classes, but fails for WhiteBox due
Class.forName initiate Class. WhiteBox has "static" section, and
initialization fails as it cannot bind to native methods
"registerNatives" and so on.
So, lets return to first one option? Just add everywhere
* @run main ClassFileInstaller sun.hotspot.WhiteBox
+ * @run main ClassFileInstaller sun.hotspot.WhiteBox$WhiteBoxPermission
Thanks.
On 10.06.2014 19:43, Igor Ignatyev wrote:
> Andrey,
>
> I don't like this idea, since it completely changes the tests.
> 'run/othervm/bootclasspath' adds all paths from CP to BCP, so the
> tests whose main idea was testing WB methods themselves (sanity,
> compiler/whitebox, ...) don't check that it's possible to use WB when
> the application isn't in BCP.
>
> Igor
>
> On 06/09/2014 06:59 PM, Andrey Zakharov wrote:
>> Hi, everybody
>> I have tested my changes on major platforms and found one bug, filed:
>> https://bugs.openjdk.java.net/browse/JDK-8046231
>> Also, i did another try to make ClassFileInstaller to copy all inner
>> classes within parent, but this fails for WhiteBox due its static
>> "registerNatives" dependency.
>>
>> Please, review suggested changes:
>> - replace ClassFileInstaller and run/othervm with
>> "run/othervm/bootclasspath".
>> bootclasspath parameter for othervm adds-Xbootclasspath/a:
>> option with ${test.src} and ${test.classes}according to
>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/share/classes/com/sun/javatest/regtest/MainAction.java.
>>
>> Is this suitable for our needs - give to test compiled WhiteBox?
>> - replace explicit -Xbootclasspath option values (".") in
>> ProcessBuilder invocations to ${test.classes} where WhiteBox has been
>> compiled.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8011397
>> Thanks.
>>
>>
>> On 23.05.2014 15:40, Andrey Zakharov wrote:
>>>
>>> On 22.05.2014 12:47, Igor Ignatyev wrote:
>>>> Andrey,
>>>>
>>>> 1. You changed dozen of tests, have you tested your changes?
>>> Locally, aurora on the way.
>>>>
>>>> 2. Your changes of year in copyright is wrong. it has to be
>>>> $first_year, [$last_year, ], see Mark's email[1] for details.
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.html
>>> Thanks, fixed. will be uploaded soon.
>>>
>>>
>>>>
>>>> Igor
>>>>
>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>
>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote:
>>>>>> Hi
>>>>>> So here is trivial patch -
>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and adding
>>>>>> main/othervm/bootclasspath
>>>>>> where this needed
>>>>>>
>>>>>> Also, some tests are modified as
>>>>>> - "-Xbootclasspath/a:.",
>>>>>> + "-Xbootclasspath/a:" + System.getProperty("test.classes"),
>>>>>>
>>>>>> Thanks.
>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011397
>>>>> Thanks.
>>>>>
>>>>>>
>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote:
>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote:
>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime and gc lists.
>>>>>>>>
>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote:
>>>>>>>>> Andrey,
>>>>>>>>>
>>>>>>>>> I've CC'ed compiler and runtime mailing list, because you're
>>>>>>>>> changes
>>>>>>>>> affect test for other components as too.
>>>>>>>>>
>>>>>>>>> I don't like your solution (but I'm not a reviewer, so treat my
>>>>>>>>> words
>>>>>>>>> just as suggestion),
>>>>>>>>> because we'll have to write more meta information for each test
>>>>>>>>> and it
>>>>>>>>> is very easy to
>>>>>>>>> forget to install WhiteBoxPermission if you don't test your test
>>>>>>>>> with
>>>>>>>>> some security manager.
>>>>>>>>>
>>>>>>>>> From my point of view, it will be better to extend
>>>>>>>>> ClassFileInstaller
>>>>>>>>>
>>>>>>>>> so it will copy not only
>>>>>>>>> a class whose name was passed as an arguments, but also all inner
>>>>>>>>> classes of that class.
>>>>>>>>> And if someone want copy only specified class without inner
>>>>>>>>> classes,
>>>>>>>>> then some option
>>>>>>>>> could be added to ClassFileInstaller to force such behaviour.
>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller
>>>>>>> altogether?
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117
>>>>>>>
>>>>>>> The reason for its existence is that the WhiteBox class needs to be
>>>>>>> on the
>>>>>>> boot class path.
>>>>>>> If we can live with having all the test's classes on the boot class
>>>>>>> path then
>>>>>>> we could use the /bootclasspath option in jtreg as stated in the
>>>>>>> RFE.
>>>>>>>
>>>>>>> /Mikael
>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Filipp.
>>>>>>>>>
>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote:
>>>>>>>>>> Hi!
>>>>>>>>>> Suggesting patch with fixes for
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397
>>>>>>>>>>
>>>>>>>>>> webrev:
>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397.tgz
>>>>>>>>>>
>>>>>>>>>> patch:
>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397.WhiteBoxPer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> mission
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>
>>>>>
>>>
>>
From vladimir.x.ivanov at oracle.com Mon Jun 16 16:00:02 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 16 Jun 2014 20:00:02 +0400
Subject: [8u20] RFR (XXS): 8033626:
assert(ex_map->jvms()->same_calls_as(_exceptions->jvms()))
failed: all collected exceptions must come from the same place
In-Reply-To: <04BD464C-BFEC-464A-9E4C-B1010CDF0951@oracle.com>
References: <539F12AF.1060607@oracle.com>
<04BD464C-BFEC-464A-9E4C-B1010CDF0951@oracle.com>
Message-ID: <539F1482.4070901@oracle.com>
Thank you, Roland.
Best regards,
Vladimir Ivanov
On 6/16/14 7:57 PM, Roland Westrelin wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8033626
>> http://cr.openjdk.java.net/~vlivanov/8033626/webrev.8u20.00/
>>
>> This is a request for a backport to 8u20. The fix was integrated into 9 on Tuesday last week and nightly testing hasn't found any issues.
>>
>> The patch from 9 applies almost cleanly (modulo small unrelated changes which cause conflict).
>>
>> Original fix:
>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dd14b24efd49
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-June/014787.html
>
> That looks good to me.
>
> Roland.
>
From dan at danny.cz Mon Jun 16 16:29:20 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Mon, 16 Jun 2014 18:29:20 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539F0CA0.3010309@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
<539AEA4D.8020204@oracle.com>
<20140613145531.559f6d943ef097550580a1f6@danny.cz>
<539E8F41.6070001@oracle.com>
<20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
<539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com>
<20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
<539F0CA0.3010309@oracle.com>
Message-ID: <20140616182920.baccf0cc83debbe522189688@danny.cz>
On Mon, 16 Jun 2014 17:26:24 +0200
Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> Hi Dan,
>
> Since you got a comment from Bengt maybe you should fix that issue
> before I upload the new webrev.
>
> I looked through the webrev and I have one additional comment. I
> would prefer if the changes in arguments.cpp was the other way,
> casting stuff to uintx instead of size_t, since we use the result of
> MAX and MIN to set flags of type uintx.
I wasn't sure what would be better approach here
> When I applied the webrev a change in
> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp got in the way
> of the patch. The patch still applies but with an offset, so patch
> complains. If you build a new webrev with the changes above, also
> pull down the latest hs-gc to get the g1CollectedHeap.cpp change.
thanks for the comments, I'll prepare new webrev hopefully tomorrow
Dan
> Thanks!
> /Jesper
>
>
> Dan Hor?k skrev 16/6/14 16:21:
> > On Mon, 16 Jun 2014 16:19:17 +0200
> > Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >
> >> Dan,
> >>
> >> I can host the webrev. Send me the zipped webrev archive and I'll
> >> upload it to cr.openjdk.
> >
> > Jesper, thanks a lot, the whole archive is at
> > http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
> >
> >
> > Dan
> >
> >> /Jesper
> >>
> >> David Holmes skrev 16/6/14 13:15:
> >>> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
> >>>> On Mon, 16 Jun 2014 16:31:29 +1000
> >>>> David Holmes <david.holmes at oracle.com> wrote:
> >>>>
> >>>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
> >>>>>> On Fri, 13 Jun 2014 14:10:53 +0200
> >>>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> >>>>>>> Then a formality comment. I think you have to post the webrev
> >>>>>>> on cr.openjdk.java.net to get the legal stuff correct.
> >>>>>>
> >>>>>> hm, I've used this procedure (my webrev, then someone
> >>>>>> privileged takes it and pushes it) few times in the past and
> >>>>>> it worked.
> >>>>>
> >>>>> We've been advised that all contributions have to come in via
> >>>>> OpenJDK infrastructure - either a webrev on cr.openjdk.java.net
> >>>>> or as attachments to mailing list mails.
> >>>>
> >>>> I understand, but AFAIK cr.openjdk.java.net is accessible only to
> >>>> people with push access, which I'm not.
> >>>
> >>> No you only need Author status, not Committer.
> >>>
> >>>> So the question is will the list
> >>>> accept 3MB attachment? It is the size of the zipped webrev. Or
> >>>> will a plain text patch suffice?
> >>>
> >>> For large webrevs you may be able to find someone to host it for
> >>> you on cr.openjdk. I don't know what limit exists on the mailing
> >>> list but I'd hate to see very large patches submitted that way.
> >>>
> >>> Cheers,
> >>> David
> >>>
> >>>
> >>>>
> >>>> Dan
> >>>>
> >>>>> David
> >>>>> -----
> >>>>>
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>> Bengt
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
> >>>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
> >>>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> Which repository is the patch built on? Since it is mostly
> >>>>>>>>> GC code it would be good if it goes in through jdk9/hs-gc.
> >>>>>>>>>
> >>>>>>>>> The changes looks good in the webrev, but the patch did not
> >>>>>>>>> apply to a recent jdk9/hs-gc. Especially the collector
> >>>>>>>>> policy code has changed a lot recently.
> >>>>>>>>>
> >>>>>>>>> I would prefer to look at the changes applied in my
> >>>>>>>>> workspace before approving it, so if you could update to a
> >>>>>>>>> recent hs-gc it would be great.
> >>>>>>>> I have refreshed the patch for the hs-gc repository, please
> >>>>>>>> see http://fedora.danny.cz/openjdk/size_t-1/webrev/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Dan
> >>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>> /Jesper
> >>>>>>>>>
> >>>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
> >>>>>>>>>> Thank you, Dan
> >>>>>>>>>>
> >>>>>>>>>> I think casting is acceptable solution. Someone in GC group
> >>>>>>>>>> should review and sponsor this since you touched GC code
> >>>>>>>>>> mostly.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>> Vladimir
> >>>>>>>>>>
> >>>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >>>>>>>>>>> Hello,
> >>>>>>>>>>>
> >>>>>>>>>>> this the last and largest part of my changes required on
> >>>>>>>>>>> s390 (32-bit) to build OpenJDK out of the box. The
> >>>>>>>>>>> MIN2/MAX2 functions are implemented using templates and
> >>>>>>>>>>> require both arguments to be of the same type. This is a
> >>>>>>>>>>> problem when one parameter is of size_t type and the
> >>>>>>>>>>> second of uintx type and the platform has size_t defined
> >>>>>>>>>>> as eg. unsigned long as on s390 (32-bit).
> >>>>>>>>>>>
> >>>>>>>>>>> As a solution [1] I chose to typecast the smaller type
> >>>>>>>>>>> (uintx) to size_t which is of same or larger size.
> >>>>>>>>>>>
> >>>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>>>>>>>>>>
> >>>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I
> >>>>>>>>>>> should be covered by Red Hat's CLA for my contributions.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> With regards
> >>>>>>>>>>>
> >>>>>>>>>>> Dan
> >>>>>>>>>>>
> >>>>>>>
From jesper.wilhelmsson at oracle.com Mon Jun 16 17:01:20 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 16 Jun 2014 19:01:20 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140616182920.baccf0cc83debbe522189688@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com> <20140613095511.5fae7c4b483bb65f073e5628@danny.cz> <539AEA4D.8020204@oracle.com> <20140613145531.559f6d943ef097550580a1f6@danny.cz> <539E8F41.6070001@oracle.com> <20140616091702.28b895ce918bdf4c58d2506f@danny.cz> <539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com> <20140616162130.ac9bec274c625241bb7fd18d@danny.cz> <539F0CA0.3010309@oracle.com>
<20140616182920.baccf0cc83debbe522189688@danny.cz>
Message-ID: <539F22E0.2080202@oracle.com>
Hi Dan,
I created a bug four this issue:
https://bugs.openjdk.java.net/browse/JDK-8046938
/Jesper
Dan Hor?k skrev 16/6/14 18:29:
> On Mon, 16 Jun 2014 17:26:24 +0200
> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>
>> Hi Dan,
>>
>> Since you got a comment from Bengt maybe you should fix that issue
>> before I upload the new webrev.
>>
>> I looked through the webrev and I have one additional comment. I
>> would prefer if the changes in arguments.cpp was the other way,
>> casting stuff to uintx instead of size_t, since we use the result of
>> MAX and MIN to set flags of type uintx.
>
> I wasn't sure what would be better approach here
>
>> When I applied the webrev a change in
>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp got in the way
>> of the patch. The patch still applies but with an offset, so patch
>> complains. If you build a new webrev with the changes above, also
>> pull down the latest hs-gc to get the g1CollectedHeap.cpp change.
>
> thanks for the comments, I'll prepare new webrev hopefully tomorrow
>
>
> Dan
>
>> Thanks!
>> /Jesper
>>
>>
>> Dan Hor?k skrev 16/6/14 16:21:
>>> On Mon, 16 Jun 2014 16:19:17 +0200
>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>
>>>> Dan,
>>>>
>>>> I can host the webrev. Send me the zipped webrev archive and I'll
>>>> upload it to cr.openjdk.
>>>
>>> Jesper, thanks a lot, the whole archive is at
>>> http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
>>>
>>>
>>> Dan
>>>
>>>> /Jesper
>>>>
>>>> David Holmes skrev 16/6/14 13:15:
>>>>> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
>>>>>> On Mon, 16 Jun 2014 16:31:29 +1000
>>>>>> David Holmes <david.holmes at oracle.com> wrote:
>>>>>>
>>>>>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
>>>>>>>> On Fri, 13 Jun 2014 14:10:53 +0200
>>>>>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>>>>>>>> Then a formality comment. I think you have to post the webrev
>>>>>>>>> on cr.openjdk.java.net to get the legal stuff correct.
>>>>>>>>
>>>>>>>> hm, I've used this procedure (my webrev, then someone
>>>>>>>> privileged takes it and pushes it) few times in the past and
>>>>>>>> it worked.
>>>>>>>
>>>>>>> We've been advised that all contributions have to come in via
>>>>>>> OpenJDK infrastructure - either a webrev on cr.openjdk.java.net
>>>>>>> or as attachments to mailing list mails.
>>>>>>
>>>>>> I understand, but AFAIK cr.openjdk.java.net is accessible only to
>>>>>> people with push access, which I'm not.
>>>>>
>>>>> No you only need Author status, not Committer.
>>>>>
>>>>>> So the question is will the list
>>>>>> accept 3MB attachment? It is the size of the zipped webrev. Or
>>>>>> will a plain text patch suffice?
>>>>>
>>>>> For large webrevs you may be able to find someone to host it for
>>>>> you on cr.openjdk. I don't know what limit exists on the mailing
>>>>> list but I'd hate to see very large patches submitted that way.
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Bengt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
>>>>>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
>>>>>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Which repository is the patch built on? Since it is mostly
>>>>>>>>>>> GC code it would be good if it goes in through jdk9/hs-gc.
>>>>>>>>>>>
>>>>>>>>>>> The changes looks good in the webrev, but the patch did not
>>>>>>>>>>> apply to a recent jdk9/hs-gc. Especially the collector
>>>>>>>>>>> policy code has changed a lot recently.
>>>>>>>>>>>
>>>>>>>>>>> I would prefer to look at the changes applied in my
>>>>>>>>>>> workspace before approving it, so if you could update to a
>>>>>>>>>>> recent hs-gc it would be great.
>>>>>>>>>> I have refreshed the patch for the hs-gc repository, please
>>>>>>>>>> see http://fedora.danny.cz/openjdk/size_t-1/webrev/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> /Jesper
>>>>>>>>>>>
>>>>>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
>>>>>>>>>>>> Thank you, Dan
>>>>>>>>>>>>
>>>>>>>>>>>> I think casting is acceptable solution. Someone in GC group
>>>>>>>>>>>> should review and sponsor this since you touched GC code
>>>>>>>>>>>> mostly.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> this the last and largest part of my changes required on
>>>>>>>>>>>>> s390 (32-bit) to build OpenJDK out of the box. The
>>>>>>>>>>>>> MIN2/MAX2 functions are implemented using templates and
>>>>>>>>>>>>> require both arguments to be of the same type. This is a
>>>>>>>>>>>>> problem when one parameter is of size_t type and the
>>>>>>>>>>>>> second of uintx type and the platform has size_t defined
>>>>>>>>>>>>> as eg. unsigned long as on s390 (32-bit).
>>>>>>>>>>>>>
>>>>>>>>>>>>> As a solution [1] I chose to typecast the smaller type
>>>>>>>>>>>>> (uintx) to size_t which is of same or larger size.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I
>>>>>>>>>>>>> should be covered by Red Hat's CLA for my contributions.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> With regards
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>
>>>>>>>>>
From jesper.wilhelmsson at oracle.com Mon Jun 16 17:43:07 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 16 Jun 2014 19:43:07 +0200
Subject: RFR(S) 8046715: Add a way to verify an extended set of command line
options
Message-ID: <539F2CAB.7010708@oracle.com>
Hi,
As stated in JDK-8046715 [1] I would like to add a call in the argument
verification to allow for verification and other initialization of extended code
- that is code not present in the OpenJDK.
Obviously this is a change I need to do in preparation for some Oracle-internal
code I want to add, but I hope that the hook to initialize extended code will be
useful to others outside of Oracle as well.
[1] Bug: https://bugs.openjdk.java.net/browse/JDK-8046715
[2] webrev: http://cr.openjdk.java.net/~jwilhelm/8046715/webrev/
Thanks!
/Jesper
From lois.foltan at oracle.com Mon Jun 16 17:45:37 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 16 Jun 2014 13:45:37 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539F1066.8080302@oracle.com>
References: <539F1066.8080302@oracle.com>
Message-ID: <539F2D41.7040901@oracle.com>
Hi Coleen,
This looks good.
Lois
On 6/16/2014 11:42 AM, Coleen Phillimore wrote:
> Summary: Add classLoader to java/lang/Class instance for fast access
>
> In order to improve performance of Class.getClassLoader() in a way to
> allow the compilers to automatically optimize this call, I added the
> classLoader to the instance of java/lang/Class. For microbenchmarks,
> this results in a 98% improvement, which was expected. For Oracle
> internal applications, this results in a 10-12% improvement on
> solaris/sparc. The increase in size of java/lang/Class can be offset
> by other changes (removing constant pool lock, or removing signers).
>
> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
> associated linked bugs for more details.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>
> There is both hotspot and jdk changes for this change. The hotspot
> changes can work without the jdk changes (check for optional field),
> but not vice-versa. I'll file another bug (and compatibility request)
> to remove JVM_GetClassLoader from hotspot.
>
> Tested with jck lang, vm, api/java_lang tests with/without jdk change,
> nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>
> Thanks,
> Coleen
>
>
From Alan.Bateman at oracle.com Mon Jun 16 18:06:21 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Jun 2014 19:06:21 +0100
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539F1066.8080302@oracle.com>
References: <539F1066.8080302@oracle.com>
Message-ID: <539F321D.80200@oracle.com>
On 16/06/2014 16:42, Coleen Phillimore wrote:
> Summary: Add classLoader to java/lang/Class instance for fast access
>
> In order to improve performance of Class.getClassLoader() in a way to
> allow the compilers to automatically optimize this call, I added the
> classLoader to the instance of java/lang/Class. For microbenchmarks,
> this results in a 98% improvement, which was expected. For Oracle
> internal applications, this results in a 10-12% improvement on
> solaris/sparc. The increase in size of java/lang/Class can be offset
> by other changes (removing constant pool lock, or removing signers).
>
> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
> associated linked bugs for more details.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>
> There is both hotspot and jdk changes for this change. The hotspot
> changes can work without the jdk changes (check for optional field),
> but not vice-versa. I'll file another bug (and compatibility request)
> to remove JVM_GetClassLoader from hotspot.
>
The jdk changes look okay to me. One thing that I mentioned to Coleen
off-list is that we have some dead code in the old verifier that uses
JVM_GetClassLoader - I don't know the history to that but it should be
checked and probably removed.
-Alan
From vladimir.x.ivanov at oracle.com Mon Jun 16 18:09:00 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 16 Jun 2014 22:09:00 +0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539F1066.8080302@oracle.com>
References: <539F1066.8080302@oracle.com>
Message-ID: <539F32BC.2010104@oracle.com>
Looks good.
Best regards,
Vladimir Ivanov
On 6/16/14 7:42 PM, Coleen Phillimore wrote:
> Summary: Add classLoader to java/lang/Class instance for fast access
>
> In order to improve performance of Class.getClassLoader() in a way to
> allow the compilers to automatically optimize this call, I added the
> classLoader to the instance of java/lang/Class. For microbenchmarks,
> this results in a 98% improvement, which was expected. For Oracle
> internal applications, this results in a 10-12% improvement on
> solaris/sparc. The increase in size of java/lang/Class can be offset
> by other changes (removing constant pool lock, or removing signers).
>
> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
> associated linked bugs for more details.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>
> There is both hotspot and jdk changes for this change. The hotspot
> changes can work without the jdk changes (check for optional field), but
> not vice-versa. I'll file another bug (and compatibility request) to
> remove JVM_GetClassLoader from hotspot.
>
> Tested with jck lang, vm, api/java_lang tests with/without jdk change,
> nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>
> Thanks,
> Coleen
>
>
From mikael.vidstedt at oracle.com Mon Jun 16 20:17:37 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 16 Jun 2014 13:17:37 -0700
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <539AA0AC.6090202@oracle.com>
References: <53979E97.1040609@oracle.com>
<5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com>
<539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com>
Message-ID: <539F50E1.7090300@oracle.com>
Thanks Erik. Another review please?
Cheers,
Mikael
On 2014-06-12 23:56, Erik Joelsson wrote:
> Looks fine to me.
>
> /Erik
>
> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>
>> I have now verified that the changes work just fine for the platforms
>> we build and test - both from the top level and when building hotspot
>> only. Taking suggestions on other tests to perform. And it would be
>> great if somebody could test the changes on on aix/ppc.
>>
>> So, kindly asking for "real"/final reviews of the changes:
>>
>> top:
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>> hotspot:
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>
>> Cheers,
>> Mikael
>>
>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>
>>> David,
>>>
>>> Thanks for the feedback. Essentially the logic in the
>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>> two different use cases:
>>>
>>> 1. ARCH being set by the JDK build system to the value of
>>> OPENJDK_TARGET_CPU_ARCH, or
>>> 2. no ARCH being set, in which case it needs to be populated -
>>> typically from uname
>>>
>>> Since Solaris and bsd both override ARCH they do not care about
>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>
>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>> think aix/ppc64 will also change slightly since the ARCH value will
>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>> the hope that somebody can help out with that.
>>>
>>>
>>> Summing it up, I have the following two webrevs:
>>>
>>> top:
>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>
>>> hotspot:
>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>
>>> With these changes I can build the normal platforms, but more
>>> verification is needed - esp. building hotspot only. Meanwhile
>>> feedback is much appreciated!
>>>
>>> Cheers,
>>> Mikael
>>>
>>> On 2014-06-10 19:45, David Holmes wrote:
>>>> Hi Mikael,
>>>>
>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>
>>>> As you note the main flow-on effect here is that the hotspot
>>>> makefiles have to be updated for the cases where
>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>> only x86 has that issue.
>>>>
>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>> both internally and in the build artifacts and bundles!
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> I need some feedback and comments on the below fix:
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>
>>>>> Background:
>>>>>
>>>>> When configuring the hotspot build the build system sets up the ARCH
>>>>> variable to reflect the target cpu. Currently the value is
>>>>> initialized
>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>> name. For
>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>> The
>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>> gradually removed in favor of the other variables.
>>>>>
>>>>> Discussion:
>>>>>
>>>>> The two candidate variables to base ARCH on are as far as I can tell
>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>> ignored on
>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>> make/<os>/makefiles/defs.make files.
>>>>>
>>>>> Before I go too far with this though I'd like to get some feedback on
>>>>> whether or not this is the right approach and what the exact value
>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>> system may
>>>>> have to be updated for some platforms to support the new value(s).
>>>>>
>>>>> Thanks,
>>>>> Mikael
>>>>>
>>>
>>
>
From christian.thalinger at oracle.com Mon Jun 16 22:11:30 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 16 Jun 2014 15:11:30 -0700
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539A1477.4030406@oracle.com>
References: <5398C681.70209@oracle.com>
<5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com>
<5399CE05.2060806@oracle.com>
<121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com>
Message-ID: <44FFB874-5521-4E5F-AA4C-D966D99A91E8@oracle.com>
Looks good.
On Jun 12, 2014, at 1:58 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
> Thank you, John! Christian suggested I take out ConstantPool::lock() and while doing so I discovered I was still using the unsafe ConstantPool::unresolved_klass_at() call. So I replaced these with ConstantPool::klass_name_at() which is safe.
>
> Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking the metaspace_lock() must not check for safepoints.
>
> I make Chris's changes and fixed these problems and retested. Most files are unchanged, but here is the updated webrev.
>
> I didn't mention before that this change saves 152 bytes per class.
>
> http://cr.openjdk.java.net/~coleenp/8026977_2/
>
> Thanks!
> Coleen
>
> On 6/12/14, 12:57 PM, John Rose wrote:
>> Reviewed. This is a good change. The code is much cleaner. Thanks. ? John
>>
>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>> +Mutex* ConstantPool::lock() {
>>>> + // Use the lock from the metaspace in the rare instance we need to lock the entries
>>>> + // in this cpool or its associated cache. Only used for setting invokedynamic cpCache
>>>> + // entry.
>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>> +}
>>>>
>>>> I?d rather see this method removed completely and use the metaspace lock explicitly in ConstantPoolCacheEntry::set_method_handle_common. Otherwise it's confusing.
>>> Ok, I can change that.
>>>
>>> Coleen
>>>
>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> wrote:
>>>>
>>>>> Summary: Write klass and resolved_references constant pool fields lock free.
>>>>>
>>>>> The constant pool values that can change were already read lock free, through the cpSlot type (lsb set for Symbol vs. Klass) for JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other values that can change were moved to the resolved_references array, which is initialized to null. Non-null is the resolved value. With a couple uses of CAS, we can eliminate the need for the constant pool lock for the constant pool changes. Error handling also changes the tag but saving the resolution exception was done under the SystemDictionary_lock, so only the tag change needs a CAS.
>>>>>
>>>>> The only remaining use for the constant pool lock is updating the cpCache for invokedynamic. There are 4 fields that need to be consistent. These now use the metaspace lock associated with the class loader that owns the constant pool, which is only held briefly. I ran some performance tests written by Sergey Kuksenko which show no regression.
>>>>>
>>>>> Other testing - ran refworkload on linux x64 with no significant results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests, hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/ <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>>
>
From coleen.phillimore at oracle.com Mon Jun 16 22:16:56 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Jun 2014 18:16:56 -0400
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <44FFB874-5521-4E5F-AA4C-D966D99A91E8@oracle.com>
References: <5398C681.70209@oracle.com>
<5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com>
<5399CE05.2060806@oracle.com>
<121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com>
<44FFB874-5521-4E5F-AA4C-D966D99A91E8@oracle.com>
Message-ID: <539F6CD8.3040205@oracle.com>
Thanks, Chris!
Coleen
On 6/16/14, 6:11 PM, Christian Thalinger wrote:
> Looks good.
>
> On Jun 12, 2014, at 1:58 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> Thank you, John! Christian suggested I take out ConstantPool::lock() and while doing so I discovered I was still using the unsafe ConstantPool::unresolved_klass_at() call. So I replaced these with ConstantPool::klass_name_at() which is safe.
>>
>> Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking the metaspace_lock() must not check for safepoints.
>>
>> I make Chris's changes and fixed these problems and retested. Most files are unchanged, but here is the updated webrev.
>>
>> I didn't mention before that this change saves 152 bytes per class.
>>
>> http://cr.openjdk.java.net/~coleenp/8026977_2/
>>
>> Thanks!
>> Coleen
>>
>> On 6/12/14, 12:57 PM, John Rose wrote:
>>> Reviewed. This is a good change. The code is much cleaner. Thanks. ? John
>>>
>>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>
>>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>>> +Mutex* ConstantPool::lock() {
>>>>> + // Use the lock from the metaspace in the rare instance we need to lock the entries
>>>>> + // in this cpool or its associated cache. Only used for setting invokedynamic cpCache
>>>>> + // entry.
>>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>>> +}
>>>>>
>>>>> I?d rather see this method removed completely and use the metaspace lock explicitly in ConstantPoolCacheEntry::set_method_handle_common. Otherwise it's confusing.
>>>> Ok, I can change that.
>>>>
>>>> Coleen
>>>>
>>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> wrote:
>>>>>
>>>>>> Summary: Write klass and resolved_references constant pool fields lock free.
>>>>>>
>>>>>> The constant pool values that can change were already read lock free, through the cpSlot type (lsb set for Symbol vs. Klass) for JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other values that can change were moved to the resolved_references array, which is initialized to null. Non-null is the resolved value. With a couple uses of CAS, we can eliminate the need for the constant pool lock for the constant pool changes. Error handling also changes the tag but saving the resolution exception was done under the SystemDictionary_lock, so only the tag change needs a CAS.
>>>>>>
>>>>>> The only remaining use for the constant pool lock is updating the cpCache for invokedynamic. There are 4 fields that need to be consistent. These now use the metaspace lock associated with the class loader that owns the constant pool, which is only held briefly. I ran some performance tests written by Sergey Kuksenko which show no regression.
>>>>>>
>>>>>> Other testing - ran refworkload on linux x64 with no significant results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests, hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/ <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>>
From coleen.phillimore at oracle.com Mon Jun 16 22:29:51 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Jun 2014 18:29:51 -0400
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
In-Reply-To: <539B0459.2040109@oracle.com>
References: <537E4DB2.5020602@oracle.com> <5398E48E.9020201@oracle.com> <53999E5D.9030403@oracle.com> <539A6556.2070107@oracle.com>
<539B0459.2040109@oracle.com>
Message-ID: <539F6FDF.5000908@oracle.com>
Zhengyu, Here is a patch with some of my comments about the code
inline because I thought that was easier. There are some suggestions,
some requests for better comments and some proposed comments. The code
looks really good. I ran out of steam on the MallocSiteTable which is
somewhat more complicated so hopefully others can also help review this.
Coleen
On 6/13/14, 10:02 AM, Zhengyu Gu wrote:
> Actually, I am working on this.
>
> It was caught in between outputStream's format check and Mikael's
> macros, I need to merge up the repo for this.
>
> There are a lot more instances in memReporter.cpp.
>
> Thanks,
>
> -Zhengyu
>
> On 6/12/2014 10:43 PM, Coleen Phillimore wrote:
>>
>> Zhengyu,
>>
>> In nativeCallStack.cpp why do you need
>> PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC? Can you change the print
>> formats to keep gcc from complaining?
>>
>> Coleen
>>
>> On 6/12/14, 8:34 AM, Zhengyu Gu wrote:
>>> Coleen,
>>>
>>> Thanks for the review.
>>>
>>> On 6/11/2014 7:21 PM, Coleen Phillimore wrote:
>>>>
>>>> Hi Zhengyu,
>>>>
>>>> I have early feedback but I haven't looked at the new files yet.
>>>> Nothing major. I like the new code and I'm glad you could add NMT
>>>> tracking to vmError reporting.
>>>>
>>>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/solaris/vm/os_solaris.cpp.udiff.html
>>>>
>>>>
>>>> + bool os::unsetenv(const char* name) {
>>>> + assert(name != NULL, "Null pointer");
>>>> + return (::unsetenv(name) == 0);
>>>> + }
>>>> +
>>>>
>>>> Can you add this to os_posix.cpp instead? Someday this duplicate
>>>> code will be consolidated so it can start in posix even though it's
>>>> not posix.
>>>>
>>> OK. I assume that aix can also use os_posix functions, right?
>>>
>>>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/os/windows/vm/os_windows.cpp.udiff.html
>>>>
>>>>
>>>> I thought the original comment was more descriptive. Is it still a
>>>> workaround?
>>>>
>>> I think we still need this workaround. Auto-merge overwrote
>>> Christian's comment, I will restore.
>>>
>>>> http://cr.openjdk.java.net/~zgu/8028541/webrev.00/src/share/vm/runtime/arguments.cpp.html
>>>>
>>>>
>>>> Can you factor lines 3596-3623 into a function like
>>>> verify_nmt_flag? Is it that you already know what nmt level is
>>>> used from the launcher and are just checking consistency and
>>>> initializing here? These cascading if() code checking options gets
>>>> too long if you're not careful.
>>>
>>> Will do.
>>>>
>>>> In memReporter.hpp
>>>>
>>>> A short comment before each class what they are for and how you
>>>> would get to this code would be nice. I think they correspond to
>>>> NMT settings (summary vs. detail). Mem*DiffReporter reports the
>>>> difference between the current memory tracked and a previous
>>>> snapshot it appears.
>>> Will do.
>>>>
>>>>
>>>> In memReporter.cpp
>>>>
>>>> Lines 302-311, you could have two functions that does this same
>>>> calculation for these values so that it doesn't get broken. The
>>>> same calculation appears 61 and 64.
>>>>
>>>> If you use size_t can you avoid eagerly scaling the amounts?
>>>> amount_in_current_scale appears 66 times which is a lot. Can you
>>>> only call the scaling when you print the amounts?
>>> I think that is what I did. All calculations are done in byte
>>> scale, only converts to current scale when checks amount > 0 in
>>> current scale, and print the number.
>>>
>>>> In MemTracker.hpp
>>>>
>>>> Line 109, I think you can assert that the JVM is single threaded.
>>>>
>>> What's the reliable method to check JVM single thread mode? I tried
>>> in early NMT implementation, but it was not reliable.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>> That's as far as I got today. This looks good!
>>>>
>>>> Coleen
>>>>
>>>> On 5/22/14, 3:19 PM, Zhengyu Gu wrote:
>>>>> This is significant rework of native memory tracking introduced in
>>>>> earlier releases.
>>>>>
>>>>> The goal of this enhancement is to improve scalability, from both
>>>>> tracking memory and CPU usage perspectives, so it can scale well
>>>>> with increased memory allocation in large applications.
>>>>>
>>>>> The enhancement is mainly focused on malloc memory tracking, whose
>>>>> activities are several magnitude higher than virtual memory, and
>>>>> was the main bottleneck in early implementation.
>>>>>
>>>>> Instead of using book keeping records for tracking malloc
>>>>> activities, new implementation co-locates tracking data along side
>>>>> with user data by using a prefixed header. The header size is 8
>>>>> bytes on 32-bit systems and 16 bytes on 64-bit systems, which
>>>>> ensure that user data also align properly.
>>>>>
>>>>> Virtual memory tracking still uses book keeping records, and
>>>>> ThreadCritical lock is always acquired to alter the records and
>>>>> related data structures.
>>>>>
>>>>> Summary tracking data is maintained in static data structures, via
>>>>> atomic operations. Malloc detail tracking call stacks are
>>>>> maintained in a lock free hashtable.
>>>>>
>>>>> The key improvements:
>>>>> 1. Up-to-date tracking report.
>>>>> 2. Detail tracking now shows multiple call frames. Number of
>>>>> frames is compilation time decision, currently default to 4.
>>>>> 3. Malloc tracking is lock free.
>>>>> 4. Tracking summary is reported in hs_err file when native
>>>>> memory tracking is enabled.
>>>>> 5. Query is faster, uses little memory and need a very little
>>>>> process.
>>>>>
>>>>> The drawback is that, malloc tracking header is always needed if
>>>>> native memory tracking has ever been enabled, even after tracking
>>>>> is shutdown.
>>>>>
>>>>> Impacts:
>>>>> The most noticeable impact for JVM developers, is that Arena now
>>>>> also take memory type as constructor parameter, besides the new
>>>>> operators.
>>>>> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode)
>>>>> Arena(mtCode)
>>>>>
>>>>> The webrev shows modification of about 60 files, but most of them
>>>>> are due to tracking API changes, mainly due to tracking stack,
>>>>> now, is an object, vs. a single pc.
>>>>>
>>>>> The most important files for this implementations are:
>>>>>
>>>>> memTracker.hpp/cpp
>>>>> mallocTracker.hpp/cpp and mallocTracker.inline.hpp
>>>>> virtualMemoryTracker.hpp/cpp
>>>>> mallocSiteTable.hpp/cpp
>>>>>
>>>>> allocationSite.hpp
>>>>> nativeCallStack.hpp/cpp
>>>>> linkedlist.hpp
>>>>>
>>>>>
>>>>> Tests:
>>>>> - JPRT
>>>>> - NMT test suite
>>>>> - vm.quick.testlist
>>>>> - Kitchensink stability test for 16+ days
>>>>> - FMW
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028541
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8028541/webrev.00/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
diff --git a/src/share/vm/memory/allocation.hpp b/src/share/vm/memory/allocation.hpp
--- a/src/share/vm/memory/allocation.hpp
+++ b/src/share/vm/memory/allocation.hpp
@@ -159,6 +159,10 @@
// is not included as validate type)
};
+// Need a comment here that if you add an enum type,you have to add it to nmtCommon.cpp
+// memory_type_names.
+
+// Why isn't MEMFLAGS type MemoryType ?
typedef size_t MEMFLAGS;
diff --git a/src/share/vm/services/mallocSiteTable.hpp b/src/share/vm/services/mallocSiteTable.hpp
--- a/src/share/vm/services/mallocSiteTable.hpp
+++ b/src/share/vm/services/mallocSiteTable.hpp
@@ -171,6 +171,9 @@
// since malloc call can come from C runtime linker.
static MallocSiteHashtableEntry* _table[table_size];
+ // Here's this number again. Or is it the same as the other one I saw twice?
+ // Can you make this const DescriptiveName = all of this and reuse? or enum.
+
// The memory for hashtable entry allocation stack object
static size_t _hash_entry_allocation_stack[(sizeof(NativeCallStack)
+ sizeof(size_t)/2) / sizeof(size_t)];
diff --git a/src/share/vm/services/mallocTracker.hpp b/src/share/vm/services/mallocTracker.hpp
--- a/src/share/vm/services/mallocTracker.hpp
+++ b/src/share/vm/services/mallocTracker.hpp
@@ -264,6 +264,7 @@
#define MAX_MALLOCSITE_TABLE_SIZE ((size_t)(1 << 16))
#define MAX_BUCKET_LENGTH ((size_t)(1 << 8))
#define MAX_MALLOC_SIZE ((size_t)(K * K * K) - 1)
+ // This doesn't seem that large. Can Arena chunks be this large?
#endif // _LP64
public:
diff --git a/src/share/vm/services/memBaseline.cpp b/src/share/vm/services/memBaseline.cpp
--- a/src/share/vm/services/memBaseline.cpp
+++ b/src/share/vm/services/memBaseline.cpp
@@ -246,6 +246,7 @@
}
}
+// See below....
void MemBaseline::malloc_sites_to_site_order() {
if (_malloc_sites_order != by_site) {
SortedLinkedList<MallocSite, compare_malloc_site, ResourceObj::ARENA>
@@ -278,6 +279,7 @@
}
}
+// Why is this twice? Oh gosh, I see it. There are 2 characters different. Please refactor this. :) Christian's suggestion sounds good.
void MemBaseline::virtual_memory_sites_to_site_order() {
if (_virtual_memory_sites_order != by_size) {
SortedLinkedList<VirtualMemoryAllocationSite, compare_virtual_memory_site, ResourceObj::ARENA>
diff --git a/src/share/vm/services/memTracker.hpp b/src/share/vm/services/memTracker.hpp
--- a/src/share/vm/services/memTracker.hpp
+++ b/src/share/vm/services/memTracker.hpp
@@ -86,6 +86,8 @@
class MemBaseline;
class Mutex;
+// Tracker was some sort of special MemTracker class iirc. Why would you use Tracker
+// and not MemTracker?
class Tracker : public StackObj {
public:
enum TrackerType {
@@ -98,6 +100,7 @@
void record(address addr, size_t size);
private:
enum TrackerType _type;
+ // Some explanation of why you are taking ThreadCritical would be good here.
ThreadCritical _tc;
};
@@ -163,6 +166,9 @@
MEMFLAGS flag = mtNone) {
if (tracking_level() < NMT_summary) return;
if (addr != NULL) {
+ // Thread critical lock is used because this code can be called by the compiler
+ // thread and in other native jvm code which does not respect safepoints
+ // Can you really do all of this while holding TC lock?
ThreadCritical tc;
VirtualMemoryTracker::add_reserved_region((address)addr, size, stack, flag);
}
@@ -224,6 +230,8 @@
}
}
+ // What do you lock with query_lock now? It's only in NMT dcmd now. I think you
+ // should move this lock to that class since that's the remaining use.
static inline Mutex* query_lock() { return _query_lock; }
// Make a final report and shutdown.
diff --git a/src/share/vm/services/virtualMemoryTracker.cpp b/src/share/vm/services/virtualMemoryTracker.cpp
--- a/src/share/vm/services/virtualMemoryTracker.cpp
+++ b/src/share/vm/services/virtualMemoryTracker.cpp
@@ -26,13 +26,17 @@
#include "runtime/threadCritical.hpp"
#include "services/virtualMemoryTracker.hpp"
+// Holds latest snapshot of virtual memory SortedLinkedList.
+// How do we know this size? You have this twice!!
size_t VirtualMemorySummary::_snapshot[(sizeof(VirtualMemorySnapshot) + sizeof(size_t) / 2) / sizeof(size_t)];
void VirtualMemorySummary::initialize() {
assert(sizeof(_snapshot) >= sizeof(VirtualMemorySnapshot), "Sanity Check");
+ // Use placement global operator new to static data area.
::new ((void*)_snapshot) VirtualMemorySnapshot();
}
+
SortedLinkedList<ReservedMemoryRegion, compare_reserved_region_base> VirtualMemoryTracker::_reserved_regions;
int compare_committed_region(const CommittedMemoryRegion& r1, const CommittedMemoryRegion& r2) {
@@ -398,13 +402,16 @@
return true;
}
-
+// When do you transition?
+// ie. Using the dcmd interface, user can transition from more or to less tracking.
bool VirtualMemoryTracker::transition(NMT_TrackingLevel from, NMT_TrackingLevel to) {
if (from == NMT_minimal) {
assert(to == NMT_summary || to == NMT_detail, "Just check");
VirtualMemorySummary::reset();
} else if (to == NMT_minimal) {
assert(from == NMT_summary || from == NMT_detail, "Just check");
+ // Do you reset or clear virtual memory summary too?
+ // Is this only at safepoint? Can you be adding a reserved region while this is being cleared?
ThreadCritical tc;
_reserved_regions.clear();
}
diff --git a/src/share/vm/services/virtualMemoryTracker.hpp b/src/share/vm/services/virtualMemoryTracker.hpp
--- a/src/share/vm/services/virtualMemoryTracker.hpp
+++ b/src/share/vm/services/virtualMemoryTracker.hpp
@@ -36,7 +36,7 @@
/*
- * Virtual memory counter
+ * Virtual memory counter (rename this VirtualMemoryCounter then)
*/
class VirtualMemory VALUE_OBJ_CLASS_SPEC {
private:
@@ -71,7 +71,7 @@
inline size_t committed() const { return _committed; }
};
-// Virtual memory allocation site, where the virtual memory is reserved.
+// Virtual memory allocation site, keeps track where the virtual memory is reserved.
class VirtualMemoryAllocationSite : public AllocationSite<VirtualMemory> {
public:
VirtualMemoryAllocationSite(const NativeCallStack& stack) :
@@ -87,6 +87,10 @@
class VirtualMemorySummary;
+// This class represents a snapshot of virtual memory at a given time.
+// The latest snapshot is saved in a static area and the current snapshot is allocated
+// in a resource area for printing the comparison.
+
class VirtualMemorySnapshot : public ResourceObj {
friend class VirtualMemorySummary;
public:
@@ -147,6 +151,7 @@
as_snapshot()->by_type(flag)->release_memory(size);
}
+ // Why do you move the reserved and committed memory???
static inline void move_reserved_memory(MEMFLAGS from, MEMFLAGS to, size_t size) {
as_snapshot()->by_type(from)->release_memory(size);
as_snapshot()->by_type(to)->reserve_memory(size);
@@ -170,6 +175,7 @@
}
private:
+ // What is this calculation? It appears twice!
static size_t _snapshot[(sizeof(VirtualMemorySnapshot) + sizeof(size_t) / 2) / sizeof(size_t)];
};
@@ -295,7 +301,6 @@
NativeCallStack _stack;
MEMFLAGS _flag;
-
bool _all_committed;
public:
ReservedMemoryRegion(address base, size_t size, const NativeCallStack& stack,
@@ -304,6 +309,7 @@
_all_committed(false) { }
+ // Should this constructor initialize _all_committed?
ReservedMemoryRegion(address base, size_t size) :
VirtualMemoryRegion(base, size), _stack(emptyStack), _flag(mtNone) { }
@@ -336,8 +342,8 @@
size_t committed_size() const;
- // move committed regions that higher than specified address to
- // the new region
+ // move committed regions that higher are than specified address to
+ // the new region (why? what is this for?)
void move_committed_regions(address addr, ReservedMemoryRegion& rgn);
inline bool all_committed() const { return _all_committed; }
@@ -362,7 +368,7 @@
}
private:
- // The committed region contains the uncommitted region, substract the uncommitted
+ // The committed region contains the uncommitted region, subtract the uncommitted
// region from this committed region
bool remove_uncommitted_region(LinkedListNode<CommittedMemoryRegion>* node,
address addr, size_t sz);
@@ -381,6 +387,8 @@
};
+// Main class called from MemTracker to track virtual memory allocations, commits and
+// deallocations.
class VirtualMemoryTracker : AllStatic {
public:
static bool initialize(NMT_TrackingLevel level);
@@ -393,6 +401,7 @@
static bool remove_released_region (address base_addr, size_t size);
static void set_reserved_region_type (address addr, MEMFLAGS flag);
+ // called by MemBaseline to create the snapshot?
static bool walk_virtual_memory(VirtualMemoryWalker* walker);
static bool transition(NMT_TrackingLevel from, NMT_TrackingLevel to);
From christian.thalinger at oracle.com Mon Jun 16 22:33:07 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 16 Jun 2014 15:33:07 -0700
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539F1066.8080302@oracle.com>
References: <539F1066.8080302@oracle.com>
Message-ID: <F51D6338-5527-4CA4-BF42-2D99E936B5F5@oracle.com>
+ template(classClassLoader_name, "classLoader") \
This should be classLoader_name.
Otherwise this looks good.
On Jun 16, 2014, at 8:42 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> Summary: Add classLoader to java/lang/Class instance for fast access
>
> In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers).
>
> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>
> There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot.
>
> Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>
> Thanks,
> Coleen
>
>
From coleen.phillimore at oracle.com Mon Jun 16 22:44:02 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Jun 2014 18:44:02 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <F51D6338-5527-4CA4-BF42-2D99E936B5F5@oracle.com>
References: <539F1066.8080302@oracle.com>
<F51D6338-5527-4CA4-BF42-2D99E936B5F5@oracle.com>
Message-ID: <539F7332.8050207@oracle.com>
On 6/16/14, 6:33 PM, Christian Thalinger wrote:
> + template(classClassLoader_name, "classLoader") \
>
> This should be classLoader_name.
Thanks, you're right, I thought there was some sort of namespace
convention (ie to say this is a field of j.l.class) from following
classRedefinedCount example but there isn't this convention.
Thanks,
Coleen
>
> Otherwise this looks good.
>
> On Jun 16, 2014, at 8:42 AM, Coleen Phillimore
> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
> wrote:
>
>> Summary: Add classLoader to java/lang/Class instance for fast access
>>
>> In order to improve performance of Class.getClassLoader() in a way to
>> allow the compilers to automatically optimize this call, I added the
>> classLoader to the instance of java/lang/Class. For microbenchmarks,
>> this results in a 98% improvement, which was expected. For Oracle
>> internal applications, this results in a 10-12% improvement on
>> solaris/sparc. The increase in size of java/lang/Class can be
>> offset by other changes (removing constant pool lock, or removing
>> signers).
>>
>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>> associated linked bugs for more details.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>> <http://cr.openjdk.java.net/%7Ecoleenp/6642881_hotspot/>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>> <http://cr.openjdk.java.net/%7Ecoleenp/6642881_jdk/>
>>
>> There is both hotspot and jdk changes for this change. The hotspot
>> changes can work without the jdk changes (check for optional field),
>> but not vice-versa. I'll file another bug (and compatibility
>> request) to remove JVM_GetClassLoader from hotspot.
>>
>> Tested with jck lang, vm, api/java_lang tests with/without jdk
>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>
>> Thanks,
>> Coleen
>>
>>
>
From coleen.phillimore at oracle.com Mon Jun 16 22:45:56 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Jun 2014 18:45:56 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539F32BC.2010104@oracle.com>
References: <539F1066.8080302@oracle.com> <539F32BC.2010104@oracle.com>
Message-ID: <539F73A4.40100@oracle.com>
Thanks Vladimir, Lois and Alan.
Coleen
On 6/16/14, 2:09 PM, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 6/16/14 7:42 PM, Coleen Phillimore wrote:
>> Summary: Add classLoader to java/lang/Class instance for fast access
>>
>> In order to improve performance of Class.getClassLoader() in a way to
>> allow the compilers to automatically optimize this call, I added the
>> classLoader to the instance of java/lang/Class. For microbenchmarks,
>> this results in a 98% improvement, which was expected. For Oracle
>> internal applications, this results in a 10-12% improvement on
>> solaris/sparc. The increase in size of java/lang/Class can be offset
>> by other changes (removing constant pool lock, or removing signers).
>>
>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>> associated linked bugs for more details.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>
>> There is both hotspot and jdk changes for this change. The hotspot
>> changes can work without the jdk changes (check for optional field), but
>> not vice-versa. I'll file another bug (and compatibility request) to
>> remove JVM_GetClassLoader from hotspot.
>>
>> Tested with jck lang, vm, api/java_lang tests with/without jdk change,
>> nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>
>> Thanks,
>> Coleen
>>
>>
From david.holmes at oracle.com Mon Jun 16 23:57:18 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Jun 2014 09:57:18 +1000
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539F0150.10508@oracle.com>
References: <5398C681.70209@oracle.com> <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com> <5399CE05.2060806@oracle.com> <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com> <539E9274.9070300@oracle.com>
<539F0150.10508@oracle.com>
Message-ID: <539F845E.70102@oracle.com>
On 17/06/2014 12:38 AM, Coleen Phillimore wrote:
>
> On 6/16/14, 2:45 AM, David Holmes wrote:
>> On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
>>>
>>> Thank you, John! Christian suggested I take out ConstantPool::lock()
>>> and while doing so I discovered I was still using the unsafe
>>> ConstantPool::unresolved_klass_at() call. So I replaced these with
>>> ConstantPool::klass_name_at() which is safe.
>>>
>>> Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking
>>> the metaspace_lock() must not check for safepoints.
>>
>> Just to be paranoid ... so all user's of this lock elide the safepoint
>> check, and no use of this lock can encounter a safepoint within the
>> locked region?
>
> Yes, to first question and I'm not sure to second. I believe we can
> have a metaspace lock and call GC. The reason it's a no-safepoint-check
> lock is that it can be taken during GC. Which sounds unnervingly
> circular. I'll have to reconstruct why this lock was done this way.
That sounds bad them. If Thread A holds the lock, Thread B will block on
it but not be safepoint-safe; if Thread A then initiates a safepoint via
GC then the safepoint won't be reachable.
> I wish there was a consistency check though. If you take a lock without
> checking for safepoint, we should give an assertion if you take the same
> lock and check for safepoint. Not sure if there's an easy way to code
> it, but I think it would be worth having.
Relatedly every block of code that takes a lock without a safepoint
check should have a NO_SAFEPOINT_VERIFIER. I wonder if that can be built
in to the lock_without_safepoint_check?
David
> Coleen
>
>>
>> David
>> -----
>>
>>> I make Chris's changes and fixed these problems and retested. Most
>>> files are unchanged, but here is the updated webrev.
>>>
>>> I didn't mention before that this change saves 152 bytes per class.
>>>
>>> http://cr.openjdk.java.net/~coleenp/8026977_2/
>>>
>>> Thanks!
>>> Coleen
>>>
>>> On 6/12/14, 12:57 PM, John Rose wrote:
>>>> Reviewed. This is a good change. The code is much cleaner. Thanks.
>>>> ? John
>>>>
>>>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>
>>>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>>>> +Mutex* ConstantPool::lock() {
>>>>>> + // Use the lock from the metaspace in the rare instance we need
>>>>>> to lock the entries
>>>>>> + // in this cpool or its associated cache. Only used for setting
>>>>>> invokedynamic cpCache
>>>>>> + // entry.
>>>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>>>> +}
>>>>>>
>>>>>> I?d rather see this method removed completely and use the metaspace
>>>>>> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
>>>>>> Otherwise it's confusing.
>>>>> Ok, I can change that.
>>>>>
>>>>> Coleen
>>>>>
>>>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> Summary: Write klass and resolved_references constant pool fields
>>>>>>> lock free.
>>>>>>>
>>>>>>> The constant pool values that can change were already read lock
>>>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
>>>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
>>>>>>> other values that can change were moved to the resolved_references
>>>>>>> array, which is initialized to null. Non-null is the resolved
>>>>>>> value. With a couple uses of CAS, we can eliminate the need for
>>>>>>> the constant pool lock for the constant pool changes. Error
>>>>>>> handling also changes the tag but saving the resolution exception
>>>>>>> was done under the SystemDictionary_lock, so only the tag change
>>>>>>> needs a CAS.
>>>>>>>
>>>>>>> The only remaining use for the constant pool lock is updating the
>>>>>>> cpCache for invokedynamic. There are 4 fields that need to be
>>>>>>> consistent. These now use the metaspace lock associated with the
>>>>>>> class loader that owns the constant pool, which is only held
>>>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
>>>>>>> which show no regression.
>>>>>>>
>>>>>>> Other testing - ran refworkload on linux x64 with no significant
>>>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>>>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>>>
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>>>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>>
>>>
>
From coleen.phillimore at oracle.com Tue Jun 17 01:45:25 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 16 Jun 2014 21:45:25 -0400
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539F845E.70102@oracle.com>
References: <5398C681.70209@oracle.com> <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com> <5399CE05.2060806@oracle.com> <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com> <539E9274.9070300@oracle.com>
<539F0150.10508@oracle.com> <539F845E.70102@oracle.com>
Message-ID: <539F9DB5.1010901@oracle.com>
On 6/16/14, 7:57 PM, David Holmes wrote:
> On 17/06/2014 12:38 AM, Coleen Phillimore wrote:
>>
>> On 6/16/14, 2:45 AM, David Holmes wrote:
>>> On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
>>>>
>>>> Thank you, John! Christian suggested I take out ConstantPool::lock()
>>>> and while doing so I discovered I was still using the unsafe
>>>> ConstantPool::unresolved_klass_at() call. So I replaced these with
>>>> ConstantPool::klass_name_at() which is safe.
>>>>
>>>> Also, Sergey Kuksenko's tests exposed a deadlock with this code.
>>>> Locking
>>>> the metaspace_lock() must not check for safepoints.
>>>
>>> Just to be paranoid ... so all user's of this lock elide the safepoint
>>> check, and no use of this lock can encounter a safepoint within the
>>> locked region?
>>
>> Yes, to first question and I'm not sure to second. I believe we can
>> have a metaspace lock and call GC. The reason it's a no-safepoint-check
>> lock is that it can be taken during GC. Which sounds unnervingly
>> circular. I'll have to reconstruct why this lock was done this way.
>
> That sounds bad them. If Thread A holds the lock, Thread B will block
> on it but not be safepoint-safe; if Thread A then initiates a
> safepoint via GC then the safepoint won't be reachable.
Yes, this is bad and the deadlock I got by not making this lock have
no_safepoint_check.
>
>> I wish there was a consistency check though. If you take a lock without
>> checking for safepoint, we should give an assertion if you take the same
>> lock and check for safepoint. Not sure if there's an easy way to code
>> it, but I think it would be worth having.
>
> Relatedly every block of code that takes a lock without a safepoint
> check should have a NO_SAFEPOINT_VERIFIER. I wonder if that can be
> built in to the lock_without_safepoint_check?
So I did a bit of research and we use no_safepoint_check because we call
this during GC (rather than doing GC while holding this lock).
But that's a good idea about adding No_Safepoint_Verifier. We could
subclass MutexLockerEx with a NSV field. I could file an RFE with this
suggestion. I don't think I want to add a lot of extra code to this change.
Did you review the code?
Coleen
>
> David
>
>> Coleen
>>
>>>
>>> David
>>> -----
>>>
>>>> I make Chris's changes and fixed these problems and retested. Most
>>>> files are unchanged, but here is the updated webrev.
>>>>
>>>> I didn't mention before that this change saves 152 bytes per class.
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8026977_2/
>>>>
>>>> Thanks!
>>>> Coleen
>>>>
>>>> On 6/12/14, 12:57 PM, John Rose wrote:
>>>>> Reviewed. This is a good change. The code is much cleaner. Thanks.
>>>>> ? John
>>>>>
>>>>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>
>>>>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>>>>> +Mutex* ConstantPool::lock() {
>>>>>>> + // Use the lock from the metaspace in the rare instance we need
>>>>>>> to lock the entries
>>>>>>> + // in this cpool or its associated cache. Only used for setting
>>>>>>> invokedynamic cpCache
>>>>>>> + // entry.
>>>>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>>>>> +}
>>>>>>>
>>>>>>> I?d rather see this method removed completely and use the metaspace
>>>>>>> lock explicitly in
>>>>>>> ConstantPoolCacheEntry::set_method_handle_common.
>>>>>>> Otherwise it's confusing.
>>>>>> Ok, I can change that.
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
>>>>>>> <coleen.phillimore at oracle.com
>>>>>>> <mailto:coleen.phillimore at oracle.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Summary: Write klass and resolved_references constant pool fields
>>>>>>>> lock free.
>>>>>>>>
>>>>>>>> The constant pool values that can change were already read lock
>>>>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
>>>>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
>>>>>>>> other values that can change were moved to the resolved_references
>>>>>>>> array, which is initialized to null. Non-null is the resolved
>>>>>>>> value. With a couple uses of CAS, we can eliminate the need for
>>>>>>>> the constant pool lock for the constant pool changes. Error
>>>>>>>> handling also changes the tag but saving the resolution exception
>>>>>>>> was done under the SystemDictionary_lock, so only the tag change
>>>>>>>> needs a CAS.
>>>>>>>>
>>>>>>>> The only remaining use for the constant pool lock is updating the
>>>>>>>> cpCache for invokedynamic. There are 4 fields that need to be
>>>>>>>> consistent. These now use the metaspace lock associated with the
>>>>>>>> class loader that owns the constant pool, which is only held
>>>>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
>>>>>>>> which show no regression.
>>>>>>>>
>>>>>>>> Other testing - ran refworkload on linux x64 with no significant
>>>>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>>>>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>>>>
>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>>>>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>>
>>>>
>>
From david.holmes at oracle.com Tue Jun 17 02:49:22 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Jun 2014 12:49:22 +1000
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <539F50E1.7090300@oracle.com>
References: <53979E97.1040609@oracle.com>
<5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com>
<539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com>
<539F50E1.7090300@oracle.com>
Message-ID: <539FACB2.2050508@oracle.com>
Hi Mikael,
Sorry for the delay ...
make/aix/makefiles/defs.make:
This change doesn't make sense to me:
48 ifneq (,$(findstring $(ARCH), ppc))
given that the logic immediately preceding this sets ARCH to either ppc
or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for
both 32-bit and 64-bit cross-builds but the earlier logic is really
precluding this. So it seems to me that the changes in this file are
completely unnecessary (or else the earlier logic also needs changing).
---
make/linux/makefiles/defs.make
This block:
86 # i686/i586 and amd64/x86_64
87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
88 ifeq ($(ARCH_DATA_MODEL), 64)
89 ARCH_DATA_MODEL = 64
90 MAKE_ARGS += LP64=1
91 PLATFORM = linux-amd64
92 VM_PLATFORM = linux_amd64
93 HS_ARCH = x86
94 else
95 ARCH_DATA_MODEL = 32
96 PLATFORM = linux-i586
97 VM_PLATFORM = linux_i486
98 HS_ARCH = x86
99 # We have to reset ARCH to i686 since SRCARCH relies on it
100 ARCH = i686
101 endif
102 endif
seems to allow the user to try and do a 64-bit build on a 32-bit build
machine. Not sure if that would get caught in an earlier sanity check?
(Same is true for the sparc block).
Also I don't think the following is actually true:
# We have to reset ARCH to i686 since SRCARCH relies on it
ARCH = i686
As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture
designator will simply map to a SRCARCH of x86, as per defs.make:
SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc
zero,$(ARCH)))
ARCH/ = x86
ARCH/sparc = sparc
ARCH/sparc64= sparc
ARCH/ia64 = ia64
ARCH/amd64 = x86
ARCH/x86_64 = x86
ARCH/ppc64 = ppc
ARCH/ppc = ppc
ARCH/arm = arm
ARCH/zero = zero
Cheers,
David
On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>
> Thanks Erik. Another review please?
>
> Cheers,
> Mikael
>
> On 2014-06-12 23:56, Erik Joelsson wrote:
>> Looks fine to me.
>>
>> /Erik
>>
>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>
>>> I have now verified that the changes work just fine for the platforms
>>> we build and test - both from the top level and when building hotspot
>>> only. Taking suggestions on other tests to perform. And it would be
>>> great if somebody could test the changes on on aix/ppc.
>>>
>>> So, kindly asking for "real"/final reviews of the changes:
>>>
>>> top:
>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>> hotspot:
>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>
>>>
>>> Cheers,
>>> Mikael
>>>
>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>
>>>> David,
>>>>
>>>> Thanks for the feedback. Essentially the logic in the
>>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>>> two different use cases:
>>>>
>>>> 1. ARCH being set by the JDK build system to the value of
>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>> typically from uname
>>>>
>>>> Since Solaris and bsd both override ARCH they do not care about
>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>
>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>> the hope that somebody can help out with that.
>>>>
>>>>
>>>> Summing it up, I have the following two webrevs:
>>>>
>>>> top:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>
>>>> hotspot:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>
>>>>
>>>> With these changes I can build the normal platforms, but more
>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>> feedback is much appreciated!
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>> Hi Mikael,
>>>>>
>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>
>>>>> As you note the main flow-on effect here is that the hotspot
>>>>> makefiles have to be updated for the cases where
>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>> only x86 has that issue.
>>>>>
>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>> both internally and in the build artifacts and bundles!
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> I need some feedback and comments on the below fix:
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>
>>>>>> Background:
>>>>>>
>>>>>> When configuring the hotspot build the build system sets up the ARCH
>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>> initialized
>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>> name. For
>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>>> The
>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>> gradually removed in favor of the other variables.
>>>>>>
>>>>>> Discussion:
>>>>>>
>>>>>> The two candidate variables to base ARCH on are as far as I can tell
>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>> ignored on
>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>
>>>>>> Before I go too far with this though I'd like to get some feedback on
>>>>>> whether or not this is the right approach and what the exact value
>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>> system may
>>>>>> have to be updated for some platforms to support the new value(s).
>>>>>>
>>>>>> Thanks,
>>>>>> Mikael
>>>>>>
>>>>
>>>
>>
>
From david.holmes at oracle.com Tue Jun 17 02:52:42 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Jun 2014 12:52:42 +1000
Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
In-Reply-To: <F87B4C04-95CE-4FB5-9C85-F1C5FB5218C4@oracle.com>
References: <58A73EC2-FD4F-498C-A38A-38D8C34DFB3D@oracle.com>
<173AECD0-7B32-4F00-BE8B-20003C6E0990@oracle.com>
<539905F1.7060509@oracle.com>
<F56C5565-69B9-4833-9A7C-D6B0FFC92ED5@oracle.com>
<F87B4C04-95CE-4FB5-9C85-F1C5FB5218C4@oracle.com>
Message-ID: <539FAD7A.1040909@oracle.com>
On 14/06/2014 11:09 AM, David DeHaven wrote:
>
> Updated. I kicked off a JPRT -bo run to be sure it doesn't break something else.
>
> http://cr.openjdk.java.net/~ddehaven/8043340/v4/
>
> Only change from previous is in make/bsd/makefiles/saproc.make, I added SA_SYSROOT_FLAGS which is set to SYSROOT_CFLAGS. I didn't want to add SYSROOT_CFLAGS to the compile command in case $(CC) expands to something that includes the same args on non-Mac platforms, this seems safer.
Thanks David. That change looks okay to me.
David H.
> -DrD-
>
>
>>
>> Yes, I was going for convenience and minimizing disturbance. I'll change how the flags are passed.
>>
>> If SDKROOT is unset then the paths point at the existing hard-coded paths in /System/Library/Frameworks, all SDKROOT does is prepend the SDK path and it's only set under certain conditions. JPRT has been perfectly happy with this change so far.
>>
>> Note that this ugliness can go away when we remove the dependencies on the JavaNativeFoundation and JavaRuntimeSupport frameworks.
>>
>> -DrD-
>>
>>> Hi David,
>>>
>>> In saproc.make:
>>>
>>> Hijacking SAARCH seems wrong - convenient perhaps, but wrong. What you are adding is nothing to do with the ARCH setting. If none of the existing variables are suitable perhaps just add SA_CFLAGS?
>>>
>>> If SDKROOT is not set is the path one that would normally exist? In particular does it exist on all our JPRT clients?
>>>
>>> Thanks,
>>> David H.
>>>
>>> On 12/06/2014 6:06 AM, David DeHaven wrote:
>>>>
>>>> Can I get hotspot signoff on the (fairly trivial) hotspot changes for this?
>>>>
>>>> The hotspot specific changes are here:
>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3/hotspot/
>>>>
>>>> Also, is there a problem if I push these through jdk9/build instead of going through hotspot?
>>>>
>>>> I'm re-submitting a JPRT run, now that JDK-8045998 has been fixed I should actually get valid results.
>>>>
>>>> -DrD-
>>>>
>>>>> From: David DeHaven <david.dehaven at oracle.com>
>>>>> Subject: Re: RFR: [9] 8043340 & 8043591: [macosx] Build system issues
>>>>> Date: June 4, 2014 16:01:29 PDT
>>>>> To: build-dev build-dev <build-dev at openjdk.java.net>
>>>>>
>>>>>
>>>>> Next (hopefully last??) update:
>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>>>>>
>>>>> (ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a separate patch)
>>>>>
>>>>> I also removed generated_configure.sh since those will be automatically generated before pushing anyways and it just keeps getting in the way.
>>>>>
>>>>>
>>>>> These comments in flags.m4 are a bit misleading and not really true:
>>>>> # FIXME: This needs to be exported in spec.gmk due to closed legacy code.
>>>>> # FIXME: clean this up, and/or move it elsewhere.
>>>>>
>>>>> So, I removed them...
>>>>>
>>>>> I also removed using SDKROOT from the env, since we ignore the environment. Only two args affect SYSROOT now, --with-sysroot and --with-sdk-name.
>>>>>
>>>>>
>>>>>
>>>>> Testing:
>>>>>
>>>>> I now have two system configurations I'm testing with:
>>>>> 1> OS X 10.8, Xcode 5 in /Applications/Xcode.app, Xcode 4.6.3 in /Applications/old/Xcode4.app (plus everything needed to build closed jdk)
>>>>> 2> OS X 10.9, Command line tools only, installed JDK 8u5, freetype and autoconf 2.69 (nothing else)
>>>>>
>>>>> System 1 tests:
>>>>> $ sudo xcode-select -switch /Applications/Xcode.app
>>>>> $ make clean; sh ./configure; make images
>>>>> ...
>>>>> 00:09:17 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>>
>>>>> $ make clean; sh ./configure --with-toolchain-path=/Applications/old/Xcode4.app/Contents/Developer/usr/bin; make images
>>>>> ...
>>>>> 00:13:37 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>> (Note that building with Xcode 5/clang is faster...)
>>>>>
>>>>>
>>>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>>>>> $ make clean; sh ./configure; make images
>>>>> Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode 4 is active
>>>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to use --with-toolchain-path or --with-toolchain-type=clang (as below)
>>>>> Hudson/JPRT should not be affected unless they also have Xcode 5 installed
>>>>>
>>>>>
>>>>> $ make clean; sh ./configure --with-toolchain-type=clang; make images
>>>>> ...
>>>>> 00:10:54 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>>
>>>>> System 2 tests:
>>>>> OpenJDK only (ignore the time, I had it pulling closed jdk while building):
>>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>>>> ...
>>>>> 00:20:26 TOTAL
>>>>> -------------------------
>>>>> Finished building OpenJDK for target 'images'
>>>>>
>>>>>
>>>>> Closed JDK (images only, deploy/install expected to fail)
>>>>> $ rm -rf build; sh ./configure --with-freetype=/opt/freetype && make images
>>>>> ...
>>>>> 00:10:05 TOTAL
>>>>> -------------------------
>>>>> Finished building Java(TM) for target 'images'
>>>>>
>>>>> -DrD-
>>>>>
>>>>
>>
>
From david.holmes at oracle.com Tue Jun 17 02:54:30 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Jun 2014 12:54:30 +1000
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539F9DB5.1010901@oracle.com>
References: <5398C681.70209@oracle.com> <5FEB59DA-434C-4EC1-8390-45CB0C6A92BB@oracle.com> <5399CE05.2060806@oracle.com> <121CBAD2-DB09-4126-BD45-5E52FE93F6C7@oracle.com>
<539A1477.4030406@oracle.com> <539E9274.9070300@oracle.com>
<539F0150.10508@oracle.com> <539F845E.70102@oracle.com>
<539F9DB5.1010901@oracle.com>
Message-ID: <539FADE6.8010904@oracle.com>
On 17/06/2014 11:45 AM, Coleen Phillimore wrote:
>
> On 6/16/14, 7:57 PM, David Holmes wrote:
>> On 17/06/2014 12:38 AM, Coleen Phillimore wrote:
>>>
>>> On 6/16/14, 2:45 AM, David Holmes wrote:
>>>> On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
>>>>>
>>>>> Thank you, John! Christian suggested I take out ConstantPool::lock()
>>>>> and while doing so I discovered I was still using the unsafe
>>>>> ConstantPool::unresolved_klass_at() call. So I replaced these with
>>>>> ConstantPool::klass_name_at() which is safe.
>>>>>
>>>>> Also, Sergey Kuksenko's tests exposed a deadlock with this code.
>>>>> Locking
>>>>> the metaspace_lock() must not check for safepoints.
>>>>
>>>> Just to be paranoid ... so all user's of this lock elide the safepoint
>>>> check, and no use of this lock can encounter a safepoint within the
>>>> locked region?
>>>
>>> Yes, to first question and I'm not sure to second. I believe we can
>>> have a metaspace lock and call GC. The reason it's a no-safepoint-check
>>> lock is that it can be taken during GC. Which sounds unnervingly
>>> circular. I'll have to reconstruct why this lock was done this way.
>>
>> That sounds bad them. If Thread A holds the lock, Thread B will block
>> on it but not be safepoint-safe; if Thread A then initiates a
>> safepoint via GC then the safepoint won't be reachable.
>
> Yes, this is bad and the deadlock I got by not making this lock have
> no_safepoint_check.
>>
>>> I wish there was a consistency check though. If you take a lock without
>>> checking for safepoint, we should give an assertion if you take the same
>>> lock and check for safepoint. Not sure if there's an easy way to code
>>> it, but I think it would be worth having.
>>
>> Relatedly every block of code that takes a lock without a safepoint
>> check should have a NO_SAFEPOINT_VERIFIER. I wonder if that can be
>> built in to the lock_without_safepoint_check?
>
> So I did a bit of research and we use no_safepoint_check because we call
> this during GC (rather than doing GC while holding this lock).
OK.
> But that's a good idea about adding No_Safepoint_Verifier. We could
> subclass MutexLockerEx with a NSV field. I could file an RFE with this
> suggestion. I don't think I want to add a lot of extra code to this
> change.
Yes RFE would be good.
> Did you review the code?
No sorry, don't know the area enough.
David
> Coleen
>
>>
>> David
>>
>>> Coleen
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>>> I make Chris's changes and fixed these problems and retested. Most
>>>>> files are unchanged, but here is the updated webrev.
>>>>>
>>>>> I didn't mention before that this change saves 152 bytes per class.
>>>>>
>>>>> http://cr.openjdk.java.net/~coleenp/8026977_2/
>>>>>
>>>>> Thanks!
>>>>> Coleen
>>>>>
>>>>> On 6/12/14, 12:57 PM, John Rose wrote:
>>>>>> Reviewed. This is a good change. The code is much cleaner. Thanks.
>>>>>> ? John
>>>>>>
>>>>>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>
>>>>>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>>>>>> +Mutex* ConstantPool::lock() {
>>>>>>>> + // Use the lock from the metaspace in the rare instance we need
>>>>>>>> to lock the entries
>>>>>>>> + // in this cpool or its associated cache. Only used for setting
>>>>>>>> invokedynamic cpCache
>>>>>>>> + // entry.
>>>>>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>>>>>> +}
>>>>>>>>
>>>>>>>> I?d rather see this method removed completely and use the metaspace
>>>>>>>> lock explicitly in
>>>>>>>> ConstantPoolCacheEntry::set_method_handle_common.
>>>>>>>> Otherwise it's confusing.
>>>>>>> Ok, I can change that.
>>>>>>>
>>>>>>> Coleen
>>>>>>>
>>>>>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
>>>>>>>> <coleen.phillimore at oracle.com
>>>>>>>> <mailto:coleen.phillimore at oracle.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Summary: Write klass and resolved_references constant pool fields
>>>>>>>>> lock free.
>>>>>>>>>
>>>>>>>>> The constant pool values that can change were already read lock
>>>>>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
>>>>>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
>>>>>>>>> other values that can change were moved to the resolved_references
>>>>>>>>> array, which is initialized to null. Non-null is the resolved
>>>>>>>>> value. With a couple uses of CAS, we can eliminate the need for
>>>>>>>>> the constant pool lock for the constant pool changes. Error
>>>>>>>>> handling also changes the tag but saving the resolution exception
>>>>>>>>> was done under the SystemDictionary_lock, so only the tag change
>>>>>>>>> needs a CAS.
>>>>>>>>>
>>>>>>>>> The only remaining use for the constant pool lock is updating the
>>>>>>>>> cpCache for invokedynamic. There are 4 fields that need to be
>>>>>>>>> consistent. These now use the metaspace lock associated with the
>>>>>>>>> class loader that owns the constant pool, which is only held
>>>>>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
>>>>>>>>> which show no regression.
>>>>>>>>>
>>>>>>>>> Other testing - ran refworkload on linux x64 with no significant
>>>>>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>>>>>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>>>>>
>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>>>>>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Coleen
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>
>
From joel.franck at oracle.com Tue Jun 17 04:38:14 2014
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Tue, 17 Jun 2014 06:38:14 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539F1066.8080302@oracle.com>
References: <539F1066.8080302@oracle.com>
Message-ID: <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
Hi Coleen,
On 16 jun 2014, at 17:42, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> Summary: Add classLoader to java/lang/Class instance for fast access
>
> In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers).
>
> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>
> There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot.
>
> Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>
Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?).
Otherwise looks good.
cheers
/Joel
From david.holmes at oracle.com Tue Jun 17 05:30:51 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Jun 2014 15:30:51 +1000
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539F56E9.3060705@oracle.com>
References: <539F1066.8080302@oracle.com>
<539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com>
<539F56E9.3060705@oracle.com>
Message-ID: <539FD28B.7000201@oracle.com>
On 17/06/2014 6:43 AM, Coleen Phillimore wrote:
>
> On 6/16/14, 1:50 PM, roger riggs wrote:
>> Hi Colleen,
>>
>> In Class.java, if only the VM creates Class objects (comment at line
>> 681),
>> and it does not use the constructor then the code (line 136) in the
>> constructor
>> to set classloader is misleading and deserves a comment.
>
> Thanks, Roger. How about this comment?
>
> /*
> * Constructor. Only the Java Virtual Machine creates Class
> * objects, but this constructor prevents a warning that
> classLoader is not
> * initialized.
> */
> private Class(ClassLoader loader) {
> classLoader = loader;
> }
Why not just initialize classloader to null when it is declared and
leave the constructor alone? The constructor exists to prevent javac
from creating a default constructor, and thus ensuring Class instances
can not be created (which is what the original comment should, but
doesn't quite, say).
David
> Coleen
>>
>> Roger
>>
>> On 6/16/2014 1:45 PM, Lois Foltan wrote:
>>> Hi Coleen,
>>> This looks good.
>>> Lois
>>>
>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote:
>>>> Summary: Add classLoader to java/lang/Class instance for fast access
>>>>
>>>> In order to improve performance of Class.getClassLoader() in a way
>>>> to allow the compilers to automatically optimize this call, I added
>>>> the classLoader to the instance of java/lang/Class. For
>>>> microbenchmarks, this results in a 98% improvement, which was
>>>> expected. For Oracle internal applications, this results in a
>>>> 10-12% improvement on solaris/sparc. The increase in size of
>>>> java/lang/Class can be offset by other changes (removing constant
>>>> pool lock, or removing signers).
>>>>
>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>>>> associated linked bugs for more details.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>>>
>>>> There is both hotspot and jdk changes for this change. The hotspot
>>>> changes can work without the jdk changes (check for optional field),
>>>> but not vice-versa. I'll file another bug (and compatibility
>>>> request) to remove JVM_GetClassLoader from hotspot.
>>>>
>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk
>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>
>>
>
From staffan.larsen at oracle.com Tue Jun 17 05:49:12 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 17 Jun 2014 07:49:12 +0200
Subject: RFR(S) 8046715: Add a way to verify an extended set of command
line options
In-Reply-To: <539F2CAB.7010708@oracle.com>
References: <539F2CAB.7010708@oracle.com>
Message-ID: <512B2745-B278-4BF4-BF47-88A12F9EA2A7@oracle.com>
Looks ok to me.
/Staffan
On 16 jun 2014, at 19:43, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> Hi,
>
> As stated in JDK-8046715 [1] I would like to add a call in the argument verification to allow for verification and other initialization of extended code - that is code not present in the OpenJDK.
>
> Obviously this is a change I need to do in preparation for some Oracle-internal code I want to add, but I hope that the hook to initialize extended code will be useful to others outside of Oracle as well.
>
> [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8046715
> [2] webrev: http://cr.openjdk.java.net/~jwilhelm/8046715/webrev/
>
> Thanks!
> /Jesper
From erik.helin at oracle.com Tue Jun 17 11:15:25 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 17 Jun 2014 13:15:25 +0200
Subject: RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected
heap size on sparcv9
In-Reply-To: <5372108E.7070508@oracle.com>
References: <5368A0D6.5050609@oracle.com> <536BA420.5000408@oracle.com>
<5372108E.7070508@oracle.com>
Message-ID: <1435735.yAz5aBB6y5@ehelin-laptop>
Hi Stefan,
sorry for the late reply, please see my comments inline.
On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
> On 2014-05-08 17:34, Erik Helin wrote:
> > Hi Stefan,
> >
> > thanks for your thorough review! Please see new webrev at:
> > http://cr.openjdk.java.net/~ehelin/8027915/webrev.01/
> >
> > and incremental webrev at:
> > http://cr.openjdk.java.net/~ehelin/8027915/webrev.00-01/
> >
> > and comments inline!
> >
> > On 2014-05-06 13:12, Stefan Johansson wrote:
> >> Hi Erik,
> >>
> >> Thanks for making page_size_for_region more strict. A few comments:
> >>
> >> src/share/vm/runtime/os.cpp
> >>
> >> With this fix page_size_for_region doesn't care about alignment at all
> >> (old version wasn't much better) and to me that feels wrong. I would
> >> expect to get a page size that the given region sizes is aligned to, but
> >> I might be missing some use case where that isn't needed.
> >
> > Agree, page_size_for_region should check alignment for large pages.
> > Added fix and regression tests.
>
> Good fix.
Thanks!
On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
> Regarding the testing, I looked at the code and the _page_sizes array is
> public. You could start of the testing with recording all "real" values
> and then set up an array that allows more testing. It would be nice to
> have a case in the alignment test that makes sure for example that for a
> 10M region you can get 2M pages but not 4M pages. If doing this you need
> to make sure the values in the _page_sizes array are set back to normal
> after the test. This would also allow the test to run even if
> UseLargePages isn't set.
I agree that this is a good idea, but I'm not fond of modifying the
_page_sizes array. Even though the VM is quite idle when the internal
vm tests are running, there is a possibility that threads running
concurrently might pick up a strange value from the _page_sizes
array. Diagnosing an eventual crash due to this might be tricky :)
What do you think of this?
On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
> > On 2014-05-06 13:12, Stefan Johansson wrote:
> >> src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
> >>
> >> For the heap we want both min and max to be a multiple of the page size
> >> so we shoud call page_size_for_region for both _min_heap_byte_size and
> >> _max_heap_byte_size and use the smallest of the two returned page sizes.
> >
> > Agree, fixed.
>
> Great!
Thanks,
Erik
> > On 2014-05-06 13:12, Stefan Johansson wrote:
> >> src/share/vm/memory/heap.cpp
> >>
> >> The current patch will not change the default behavior so I'm fine with
> >> just calling page_size_for_region once using reserved_size, but someone
> >> with more insight might know if we should handle it the same way as the
> >> generationSizer and use both committed and reserved.
> >
> > Since I'm not sure how the compiler guys want to handle this, I opted
> > for the safe alternative and updated the patch to be backwards
> > compatible with the old code (except slightly more strict).
>
> I agree that this is probably the correct solution, but it would be nice
> to hear what the compiler guys think. As you say, this is a little more
> strict and there might be cases where we now stop getting large pages
> where we used to before.
>
> To summarize, I think the changes are good but wouldn't mind some
> improved tests for it.
>
> Stefan
>
> > Thanks,
> > Erik
> >
> >> Thanks,
> >> Stefan
> >>
> >> On 2014-05-06 10:44, Erik Helin wrote:
> >>> Hi all,
> >>>
> >>> this patch changes
> >>> os::page_size_for_region(min_size, max_size, min_pages) to always
> >>> guarantee that the returned page size <= max_size / min_pages. Prior
> >>> to this patch, page_size_for_region could return a page size larger
> >>> than max_size / min_pages. This can cause some unexpected behavior
> >>> for code using page_size_for_region, such as the following regression
> >>> tests:
> >>>
> >>> http://cr.openjdk.java.net/~ehelin/8027915/regression-test/
> >>>
> >>> As the test shows, if you have a 2 MB region and you must use at least
> >>> 2 pages, you would still get back 2 MB as the page size on a Linux
> >>> machine that supports 2 MB large pages. The reason for this is
> >>> explained in a comment above the function in os.hpp:
> >>>
> >>> // The current implementation ignores min_pages if a larger page
> >>> // size is an exact multiple of both region_min_size and
> >>> // region_max_size. This allows larger pages to be used when doing
> >>> // so would not cause fragmentation; in particular, a single page can
> >>> // be used when region_min_size == region_max_size == a supported page
> >>> // size.
> >>>
> >>> Reducing fragmentation of large pages is good but the varying return
> >>> value makes it very hard to depend on os::page_size_for_region in
> >>> calculations (for example when sizing the heap).
> >>>
> >>> This patch removes the fragmentation prevention mechanism, simplifies
> >>> the function and adds a regression tests:
> >>>
> >>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00/
> >>>
> >>> Testing:
> >>> - JPRT
> >>>
> >>> Thanks,
> >>> Erik
From jesper.wilhelmsson at oracle.com Tue Jun 17 09:49:31 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 17 Jun 2014 11:49:31 +0200
Subject: RFR(S) 8046715: Add a way to verify an extended set of command
line options
In-Reply-To: <512B2745-B278-4BF4-BF47-88A12F9EA2A7@oracle.com>
References: <539F2CAB.7010708@oracle.com>
<512B2745-B278-4BF4-BF47-88A12F9EA2A7@oracle.com>
Message-ID: <EE9B8C60-FAFD-43E3-B3F4-7FB20648209E@oracle.com>
Thanks for reviewing!
/Jesper
> 17 jun 2014 kl. 07:49 skrev Staffan Larsen <staffan.larsen at oracle.com>:
>
> Looks ok to me.
>
> /Staffan
>
>> On 16 jun 2014, at 19:43, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>
>> Hi,
>>
>> As stated in JDK-8046715 [1] I would like to add a call in the argument verification to allow for verification and other initialization of extended code - that is code not present in the OpenJDK.
>>
>> Obviously this is a change I need to do in preparation for some Oracle-internal code I want to add, but I hope that the hook to initialize extended code will be useful to others outside of Oracle as well.
>>
>> [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8046715
>> [2] webrev: http://cr.openjdk.java.net/~jwilhelm/8046715/webrev/
>>
>> Thanks!
>> /Jesper
>
From mikael.gerdin at oracle.com Tue Jun 17 10:11:51 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 17 Jun 2014 12:11:51 +0200
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <539F0150.10508@oracle.com>
References: <5398C681.70209@oracle.com> <539E9274.9070300@oracle.com>
<539F0150.10508@oracle.com>
Message-ID: <8512167.xIYu4dz7Hb@mgerdin03>
On Monday 16 June 2014 10.38.08 Coleen Phillimore wrote:
> On 6/16/14, 2:45 AM, David Holmes wrote:
> > On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
> >> Thank you, John! Christian suggested I take out ConstantPool::lock()
> >> and while doing so I discovered I was still using the unsafe
> >> ConstantPool::unresolved_klass_at() call. So I replaced these with
> >> ConstantPool::klass_name_at() which is safe.
> >>
> >> Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking
> >> the metaspace_lock() must not check for safepoints.
> >
> > Just to be paranoid ... so all user's of this lock elide the safepoint
> > check, and no use of this lock can encounter a safepoint within the
> > locked region?
>
> Yes, to first question and I'm not sure to second. I believe we can
> have a metaspace lock and call GC. The reason it's a no-safepoint-check
> lock is that it can be taken during GC. Which sounds unnervingly
> circular. I'll have to reconstruct why this lock was done this way.
>
> I wish there was a consistency check though. If you take a lock without
> checking for safepoint, we should give an assertion if you take the same
> lock and check for safepoint. Not sure if there's an easy way to code
> it, but I think it would be worth having.
Can't we use the type system for this?
Have a
class NoSafepointCheckMutex which always elides safepoint checks
and a
class Mutex which does not allow elision of safepoint checks.
/Mikael
>
> Coleen
>
> > David
> > -----
> >
> >> I make Chris's changes and fixed these problems and retested. Most
> >> files are unchanged, but here is the updated webrev.
> >>
> >> I didn't mention before that this change saves 152 bytes per class.
> >>
> >> http://cr.openjdk.java.net/~coleenp/8026977_2/
> >>
> >> Thanks!
> >> Coleen
> >>
> >> On 6/12/14, 12:57 PM, John Rose wrote:
> >>> Reviewed. This is a good change. The code is much cleaner. Thanks.
> >>> ? John
> >>>
> >>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
> >>>
> >>> <coleen.phillimore at oracle.com> wrote:
> >>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
> >>>>> +Mutex* ConstantPool::lock() {
> >>>>> + // Use the lock from the metaspace in the rare instance we need
> >>>>> to lock the entries
> >>>>> + // in this cpool or its associated cache. Only used for setting
> >>>>> invokedynamic cpCache
> >>>>> + // entry.
> >>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
> >>>>> +}
> >>>>>
> >>>>> I?d rather see this method removed completely and use the metaspace
> >>>>> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
> >>>>> Otherwise it's confusing.
> >>>>
> >>>> Ok, I can change that.
> >>>>
> >>>> Coleen
> >>>>
> >>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
> >>>>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
> >>>>>
> >>>>> wrote:
> >>>>>> Summary: Write klass and resolved_references constant pool fields
> >>>>>> lock free.
> >>>>>>
> >>>>>> The constant pool values that can change were already read lock
> >>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
> >>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
> >>>>>> other values that can change were moved to the resolved_references
> >>>>>> array, which is initialized to null. Non-null is the resolved
> >>>>>> value. With a couple uses of CAS, we can eliminate the need for
> >>>>>> the constant pool lock for the constant pool changes. Error
> >>>>>> handling also changes the tag but saving the resolution exception
> >>>>>> was done under the SystemDictionary_lock, so only the tag change
> >>>>>> needs a CAS.
> >>>>>>
> >>>>>> The only remaining use for the constant pool lock is updating the
> >>>>>> cpCache for invokedynamic. There are 4 fields that need to be
> >>>>>> consistent. These now use the metaspace lock associated with the
> >>>>>> class loader that owns the constant pool, which is only held
> >>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
> >>>>>> which show no regression.
> >>>>>>
> >>>>>> Other testing - ran refworkload on linux x64 with no significant
> >>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
> >>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
> >>>>>>
> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
> >>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Coleen
From stefan.johansson at oracle.com Tue Jun 17 12:26:10 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 17 Jun 2014 14:26:10 +0200
Subject: RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected
heap size on sparcv9
In-Reply-To: <1435735.yAz5aBB6y5@ehelin-laptop>
References: <5368A0D6.5050609@oracle.com> <536BA420.5000408@oracle.com>
<5372108E.7070508@oracle.com> <1435735.yAz5aBB6y5@ehelin-laptop>
Message-ID: <53A033E2.8010806@oracle.com>
On 2014-06-17 13:15, Erik Helin wrote:
> Hi Stefan,
>
> sorry for the late reply, please see my comments inline.
>
> On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
>> On 2014-05-08 17:34, Erik Helin wrote:
>>> Hi Stefan,
>>>
>>> thanks for your thorough review! Please see new webrev at:
>>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.01/
>>>
>>> and incremental webrev at:
>>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00-01/
>>>
>>> and comments inline!
>>>
>>> On 2014-05-06 13:12, Stefan Johansson wrote:
>>>> Hi Erik,
>>>>
>>>> Thanks for making page_size_for_region more strict. A few comments:
>>>>
>>>> src/share/vm/runtime/os.cpp
>>>>
>>>> With this fix page_size_for_region doesn't care about alignment at all
>>>> (old version wasn't much better) and to me that feels wrong. I would
>>>> expect to get a page size that the given region sizes is aligned to, but
>>>> I might be missing some use case where that isn't needed.
>>> Agree, page_size_for_region should check alignment for large pages.
>>> Added fix and regression tests.
>> Good fix.
> Thanks!
>
> On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
>> Regarding the testing, I looked at the code and the _page_sizes array is
>> public. You could start of the testing with recording all "real" values
>> and then set up an array that allows more testing. It would be nice to
>> have a case in the alignment test that makes sure for example that for a
>> 10M region you can get 2M pages but not 4M pages. If doing this you need
>> to make sure the values in the _page_sizes array are set back to normal
>> after the test. This would also allow the test to run even if
>> UseLargePages isn't set.
> I agree that this is a good idea, but I'm not fond of modifying the
> _page_sizes array. Even though the VM is quite idle when the internal
> vm tests are running, there is a possibility that threads running
> concurrently might pick up a strange value from the _page_sizes
> array. Diagnosing an eventual crash due to this might be tricky :)
>
> What do you think of this?
I agree, and as we discussed off-line, this kind of tests would be
easier to write if we had a better unit-testing framework. With that in
mind I'm ok with leaving the test as is for now.
Thanks,
Stefan
>
> On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
>>> On 2014-05-06 13:12, Stefan Johansson wrote:
>>>> src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
>>>>
>>>> For the heap we want both min and max to be a multiple of the page size
>>>> so we shoud call page_size_for_region for both _min_heap_byte_size and
>>>> _max_heap_byte_size and use the smallest of the two returned page sizes.
>>> Agree, fixed.
>> Great!
> Thanks,
> Erik
>
>>> On 2014-05-06 13:12, Stefan Johansson wrote:
>>>> src/share/vm/memory/heap.cpp
>>>>
>>>> The current patch will not change the default behavior so I'm fine with
>>>> just calling page_size_for_region once using reserved_size, but someone
>>>> with more insight might know if we should handle it the same way as the
>>>> generationSizer and use both committed and reserved.
>>> Since I'm not sure how the compiler guys want to handle this, I opted
>>> for the safe alternative and updated the patch to be backwards
>>> compatible with the old code (except slightly more strict).
>> I agree that this is probably the correct solution, but it would be nice
>> to hear what the compiler guys think. As you say, this is a little more
>> strict and there might be cases where we now stop getting large pages
>> where we used to before.
>>
>> To summarize, I think the changes are good but wouldn't mind some
>> improved tests for it.
>>
>> Stefan
>>
>>> Thanks,
>>> Erik
>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>> On 2014-05-06 10:44, Erik Helin wrote:
>>>>> Hi all,
>>>>>
>>>>> this patch changes
>>>>> os::page_size_for_region(min_size, max_size, min_pages) to always
>>>>> guarantee that the returned page size <= max_size / min_pages. Prior
>>>>> to this patch, page_size_for_region could return a page size larger
>>>>> than max_size / min_pages. This can cause some unexpected behavior
>>>>> for code using page_size_for_region, such as the following regression
>>>>> tests:
>>>>>
>>>>> http://cr.openjdk.java.net/~ehelin/8027915/regression-test/
>>>>>
>>>>> As the test shows, if you have a 2 MB region and you must use at least
>>>>> 2 pages, you would still get back 2 MB as the page size on a Linux
>>>>> machine that supports 2 MB large pages. The reason for this is
>>>>> explained in a comment above the function in os.hpp:
>>>>>
>>>>> // The current implementation ignores min_pages if a larger page
>>>>> // size is an exact multiple of both region_min_size and
>>>>> // region_max_size. This allows larger pages to be used when doing
>>>>> // so would not cause fragmentation; in particular, a single page can
>>>>> // be used when region_min_size == region_max_size == a supported page
>>>>> // size.
>>>>>
>>>>> Reducing fragmentation of large pages is good but the varying return
>>>>> value makes it very hard to depend on os::page_size_for_region in
>>>>> calculations (for example when sizing the heap).
>>>>>
>>>>> This patch removes the fragmentation prevention mechanism, simplifies
>>>>> the function and adds a regression tests:
>>>>>
>>>>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00/
>>>>>
>>>>> Testing:
>>>>> - JPRT
>>>>>
>>>>> Thanks,
>>>>> Erik
From markus.gronlund at oracle.com Tue Jun 17 16:08:38 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Tue, 17 Jun 2014 09:08:38 -0700 (PDT)
Subject: RFR(S) 8046715: Add a way to verify an extended set of command
line options
In-Reply-To: <539F2CAB.7010708@oracle.com>
References: <539F2CAB.7010708@oracle.com>
Message-ID: <542ddc6c-5964-4f51-854f-2be80bc3c1d2@default>
Looks good.
/Markus
-----Original Message-----
From: Jesper Wilhelmsson
Sent: den 16 juni 2014 19:43
To: hotspot-dev at openjdk.java.net Developers
Subject: RFR(S) 8046715: Add a way to verify an extended set of command line options
Hi,
As stated in JDK-8046715 [1] I would like to add a call in the argument verification to allow for verification and other initialization of extended code
- that is code not present in the OpenJDK.
Obviously this is a change I need to do in preparation for some Oracle-internal code I want to add, but I hope that the hook to initialize extended code will be useful to others outside of Oracle as well.
[1] Bug: https://bugs.openjdk.java.net/browse/JDK-8046715
[2] webrev: http://cr.openjdk.java.net/~jwilhelm/8046715/webrev/
Thanks!
/Jesper
From lev.priima at oracle.com Tue Jun 17 16:08:09 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 17 Jun 2014 20:08:09 +0400
Subject: RFR: 8041794: remove bytecodes_<arch>.{cpp,hpp} files
Message-ID: <53A067E9.2070800@oracle.com>
Hi,
Problem:
We don't have any platform specific bytecodes and these files are empty:
hs-comp/hotspot$ find -name bytecodes_\* | grep -v "/.hg/"
./src/cpu/ppc/vm/bytecodes_ppc.cpp
./src/cpu/ppc/vm/bytecodes_ppc.hpp
./src/cpu/sparc/vm/bytecodes_sparc.cpp
./src/cpu/sparc/vm/bytecodes_sparc.hpp
./src/cpu/x86/vm/bytecodes_x86.cpp
./src/cpu/x86/vm/bytecodes_x86.hpp
./src/cpu/zero/vm/bytecodes_zero.cpp
./src/cpu/zero/vm/bytecodes_zero.hpp
.hpp's are only included in bytecodes.hpp:
hs-comp/hotspot$ grep -rn \"bytecodes_\* src
src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Parser.java:79:
public static final String BYTECODES_ELEMENT = "bytecodes";
src/share/vm/interpreter/bytecodes.hpp:292:# include "bytecodes_x86.hpp"
src/share/vm/interpreter/bytecodes.hpp:295:# include "bytecodes_sparc.hpp"
src/share/vm/interpreter/bytecodes.hpp:298:# include "bytecodes_zero.hpp"
src/share/vm/interpreter/bytecodes.hpp:301:# include "bytecodes_arm.hpp"
src/share/vm/interpreter/bytecodes.hpp:304:# include "bytecodes_ppc.hpp"
All bytecodes_<arch>.cpp files have empty implementations of their
functions.
Function:
src/share/vm/interpreter/bytecodes.hpp:335: static Code
pd_base_code_for(Code code);
with empty implementation in each platform-specific bytecodes_* file is
never called.
Solution:
I've removed these files and include directives of them. Also I removed
two function declarations and one call-statement of pd_initialize().
Bug:
https://bugs.openjdk.java.net/browse/JDK-8041794
Webrev:
http://cr.openjdk.java.net/~iignatyev/lpriima/8041794/webrev.00/
Testing:
Jprt build and tests
--
Lev
From jesper.wilhelmsson at oracle.com Tue Jun 17 16:14:00 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 17 Jun 2014 18:14:00 +0200
Subject: RFR(S) 8046715: Add a way to verify an extended set of command
line options
In-Reply-To: <542ddc6c-5964-4f51-854f-2be80bc3c1d2@default>
References: <539F2CAB.7010708@oracle.com>
<542ddc6c-5964-4f51-854f-2be80bc3c1d2@default>
Message-ID: <53A06948.9060207@oracle.com>
Thanks!
/Jesper
Markus Gr?nlund skrev 17/6/14 18:08:
> Looks good.
>
> /Markus
>
> -----Original Message-----
> From: Jesper Wilhelmsson
> Sent: den 16 juni 2014 19:43
> To: hotspot-dev at openjdk.java.net Developers
> Subject: RFR(S) 8046715: Add a way to verify an extended set of command line options
>
> Hi,
>
> As stated in JDK-8046715 [1] I would like to add a call in the argument verification to allow for verification and other initialization of extended code
> - that is code not present in the OpenJDK.
>
> Obviously this is a change I need to do in preparation for some Oracle-internal code I want to add, but I hope that the hook to initialize extended code will be useful to others outside of Oracle as well.
>
> [1] Bug: https://bugs.openjdk.java.net/browse/JDK-8046715
> [2] webrev: http://cr.openjdk.java.net/~jwilhelm/8046715/webrev/
>
> Thanks!
> /Jesper
>
From christian.thalinger at oracle.com Tue Jun 17 17:37:49 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 17 Jun 2014 10:37:49 -0700
Subject: RFR: 8041794: remove bytecodes_<arch>.{cpp,hpp} files
In-Reply-To: <53A067E9.2070800@oracle.com>
References: <53A067E9.2070800@oracle.com>
Message-ID: <CDA9A18E-862B-49B2-857D-C5452811C340@oracle.com>
Looks good. Thanks for picking that one up.
On Jun 17, 2014, at 9:08 AM, Lev Priima <lev.priima at oracle.com> wrote:
> Hi,
>
> Problem:
> We don't have any platform specific bytecodes and these files are empty:
> hs-comp/hotspot$ find -name bytecodes_\* | grep -v "/.hg/"
> ./src/cpu/ppc/vm/bytecodes_ppc.cpp
> ./src/cpu/ppc/vm/bytecodes_ppc.hpp
> ./src/cpu/sparc/vm/bytecodes_sparc.cpp
> ./src/cpu/sparc/vm/bytecodes_sparc.hpp
> ./src/cpu/x86/vm/bytecodes_x86.cpp
> ./src/cpu/x86/vm/bytecodes_x86.hpp
> ./src/cpu/zero/vm/bytecodes_zero.cpp
> ./src/cpu/zero/vm/bytecodes_zero.hpp
>
> .hpp's are only included in bytecodes.hpp:
> hs-comp/hotspot$ grep -rn \"bytecodes_\* src
> src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Parser.java:79: public static final String BYTECODES_ELEMENT = "bytecodes";
> src/share/vm/interpreter/bytecodes.hpp:292:# include "bytecodes_x86.hpp"
> src/share/vm/interpreter/bytecodes.hpp:295:# include "bytecodes_sparc.hpp"
> src/share/vm/interpreter/bytecodes.hpp:298:# include "bytecodes_zero.hpp"
> src/share/vm/interpreter/bytecodes.hpp:301:# include "bytecodes_arm.hpp"
> src/share/vm/interpreter/bytecodes.hpp:304:# include "bytecodes_ppc.hpp"
>
> All bytecodes_<arch>.cpp files have empty implementations of their functions.
> Function:
> src/share/vm/interpreter/bytecodes.hpp:335: static Code pd_base_code_for(Code code);
> with empty implementation in each platform-specific bytecodes_* file is never called.
>
>
> Solution:
> I've removed these files and include directives of them. Also I removed two function declarations and one call-statement of pd_initialize().
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8041794
>
> Webrev:
> http://cr.openjdk.java.net/~iignatyev/lpriima/8041794/webrev.00/
>
> Testing:
> Jprt build and tests
>
> --
> Lev
>
From zhengyu.gu at oracle.com Tue Jun 17 19:05:33 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 17 Jun 2014 15:05:33 -0400
Subject: RFR (L) 8028541: Native Memory Tracking enhancement
In-Reply-To: <539F6FDF.5000908@oracle.com>
References: <537E4DB2.5020602@oracle.com> <5398E48E.9020201@oracle.com> <53999E5D.9030403@oracle.com> <539A6556.2070107@oracle.com> <539B0459.2040109@oracle.com>
<539F6FDF.5000908@oracle.com>
Message-ID: <53A0917D.2000900@oracle.com>
Thanks Coleen.
-Zhengyu
On 6/16/2014 6:29 PM, Coleen Phillimore wrote:
>
> On 6/13/14, 10:02 AM, Zhengyu Gu wrote:
From mikael.vidstedt at oracle.com Tue Jun 17 19:11:16 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 17 Jun 2014 12:11:16 -0700
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <539FACB2.2050508@oracle.com>
References: <53979E97.1040609@oracle.com>
<5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com>
<539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com>
<539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com>
Message-ID: <53A092D4.3060100@oracle.com>
New webrev here (only the hotspot part, the webrev for top hasn't changed):
http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/
Comments inline.
On 2014-06-16 19:49, David Holmes wrote:
> Hi Mikael,
>
> Sorry for the delay ...
>
> make/aix/makefiles/defs.make:
>
> This change doesn't make sense to me:
>
> 48 ifneq (,$(findstring $(ARCH), ppc))
>
> given that the logic immediately preceding this sets ARCH to either
> ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow
> for both 32-bit and 64-bit cross-builds but the earlier logic is
> really precluding this. So it seems to me that the changes in this
> file are completely unnecessary (or else the earlier logic also needs
> changing).
Indeed, that is correct - I missed the fact that ARCH is always
overriden to be either ppc or ppc64. The old logic is unnecessarily hard
to follow, but I guess that's in line with our hotspot Makefiles in
general ;)
I'll revert the changes to the file and add a mental note to self and
others that linux appears to be the only platform where the incoming
value of ARCH is actually honored - it's ignored/overridden on Solaris,
BSD and AIX.
> make/linux/makefiles/defs.make
>
> This block:
>
> 86 # i686/i586 and amd64/x86_64
> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
> 88 ifeq ($(ARCH_DATA_MODEL), 64)
> 89 ARCH_DATA_MODEL = 64
> 90 MAKE_ARGS += LP64=1
> 91 PLATFORM = linux-amd64
> 92 VM_PLATFORM = linux_amd64
> 93 HS_ARCH = x86
> 94 else
> 95 ARCH_DATA_MODEL = 32
> 96 PLATFORM = linux-i586
> 97 VM_PLATFORM = linux_i486
> 98 HS_ARCH = x86
> 99 # We have to reset ARCH to i686 since SRCARCH relies on it
> 100 ARCH = i686
> 101 endif
> 102 endif
>
> seems to allow the user to try and do a 64-bit build on a 32-bit build
> machine. Not sure if that would get caught in an earlier sanity check?
> (Same is true for the sparc block).
While the changes are primarily just intended to cut down on the
duplication I don't immediately see the reason why we wouldn't want to
allow compiling a 64-bit VM from a 32-bit machine? We're cross compiling
all sorts of platforms, so why not allow this if the compiler supports
it? I'd prefer to keep it this way.
> Also I don't think the following is actually true:
>
> # We have to reset ARCH to i686 since SRCARCH relies on it
> ARCH = i686
>
> As long as ARCH is not amd64 and not x86_64 any 32-bit x86
> architecture designator will simply map to a SRCARCH of x86, as per
> defs.make:
>
> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm
> ppc zero,$(ARCH)))
> ARCH/ = x86
> ARCH/sparc = sparc
> ARCH/sparc64= sparc
> ARCH/ia64 = ia64
> ARCH/amd64 = x86
> ARCH/x86_64 = x86
> ARCH/ppc64 = ppc
> ARCH/ppc = ppc
> ARCH/arm = arm
> ARCH/zero = zero
Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64,
ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about
cleaning that up before I sent out the first webrev, but soon found
myself doing way more cleanup than was healthy for this specific change.
However, since I had to update this change anyway I removed the ARCH
reset part.
Cheers,
Mikael
>
>
> Cheers,
> David
>
> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>>
>> Thanks Erik. Another review please?
>>
>> Cheers,
>> Mikael
>>
>> On 2014-06-12 23:56, Erik Joelsson wrote:
>>> Looks fine to me.
>>>
>>> /Erik
>>>
>>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>>
>>>> I have now verified that the changes work just fine for the platforms
>>>> we build and test - both from the top level and when building hotspot
>>>> only. Taking suggestions on other tests to perform. And it would be
>>>> great if somebody could test the changes on on aix/ppc.
>>>>
>>>> So, kindly asking for "real"/final reviews of the changes:
>>>>
>>>> top:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>
>>>> hotspot:
>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>>
>>>>> David,
>>>>>
>>>>> Thanks for the feedback. Essentially the logic in the
>>>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>>>> two different use cases:
>>>>>
>>>>> 1. ARCH being set by the JDK build system to the value of
>>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>>> typically from uname
>>>>>
>>>>> Since Solaris and bsd both override ARCH they do not care about
>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>>
>>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>>> the hope that somebody can help out with that.
>>>>>
>>>>>
>>>>> Summing it up, I have the following two webrevs:
>>>>>
>>>>> top:
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>
>>>>>
>>>>> hotspot:
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>
>>>>>
>>>>>
>>>>> With these changes I can build the normal platforms, but more
>>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>>> feedback is much appreciated!
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>>> Hi Mikael,
>>>>>>
>>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>>
>>>>>> As you note the main flow-on effect here is that the hotspot
>>>>>> makefiles have to be updated for the cases where
>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>>> only x86 has that issue.
>>>>>>
>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>>> both internally and in the build artifacts and bundles!
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> I need some feedback and comments on the below fix:
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>>
>>>>>>>
>>>>>>> Background:
>>>>>>>
>>>>>>> When configuring the hotspot build the build system sets up the
>>>>>>> ARCH
>>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>>> initialized
>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>>> name. For
>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>>>> The
>>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>>> gradually removed in favor of the other variables.
>>>>>>>
>>>>>>> Discussion:
>>>>>>>
>>>>>>> The two candidate variables to base ARCH on are as far as I can
>>>>>>> tell
>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single,
>>>>>>> well
>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }.
>>>>>>> Together
>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>>> ignored on
>>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>>
>>>>>>> Before I go too far with this though I'd like to get some
>>>>>>> feedback on
>>>>>>> whether or not this is the right approach and what the exact value
>>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>>> system may
>>>>>>> have to be updated for some platforms to support the new value(s).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mikael
>>>>>>>
>>>>>
>>>>
>>>
>>
From coleen.phillimore at oracle.com Tue Jun 17 19:29:28 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 17 Jun 2014 15:29:28 -0400
Subject: RFR (xs) 8039150: host_klass invariant fails when verifying newly
loaded JSR-292 anonymous classes
Message-ID: <53A09718.7070503@oracle.com>
Summary: Initialize host_klass while parsing the class with the other
initializations.
We really should initialize more fields in metadata constructors rather
than outside them in parseClassFile but this is a smaller change.
Tested with fast.vm.quick.testlist and java/lang/invoke tests and
verified dacapo with VerifyBefore and AfterGC.
open webrev at http://cr.openjdk.java.net/~coleenp/8039150/
bug link https://bugs.openjdk.java.net/browse/JDK-8039150
Thanks,
Coleen
From stefan.karlsson at oracle.com Tue Jun 17 19:40:57 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 17 Jun 2014 21:40:57 +0200
Subject: RFR (xs) 8039150: host_klass invariant fails when verifying newly
loaded JSR-292 anonymous classes
In-Reply-To: <53A09718.7070503@oracle.com>
References: <53A09718.7070503@oracle.com>
Message-ID: <53A099C9.2080509@oracle.com>
On 2014-06-17 21:29, Coleen Phillimore wrote:
> Summary: Initialize host_klass while parsing the class with the other
> initializations.
>
> We really should initialize more fields in metadata constructors
> rather than outside them in parseClassFile but this is a smaller change.
>
> Tested with fast.vm.quick.testlist and java/lang/invoke tests and
> verified dacapo with VerifyBefore and AfterGC.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8039150/
Looks good.
StefanK
> bug link https://bugs.openjdk.java.net/browse/JDK-8039150
>
>
> Thanks,
> Coleen
From serguei.spitsyn at oracle.com Tue Jun 17 19:41:51 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 17 Jun 2014 12:41:51 -0700
Subject: RFR (xs) 8039150: host_klass invariant fails when verifying newly
loaded JSR-292 anonymous classes
In-Reply-To: <53A09718.7070503@oracle.com>
References: <53A09718.7070503@oracle.com>
Message-ID: <53A099FF.30106@oracle.com>
Coleen,
It looks good to me.
Thanks,
Serguei
On 6/17/14 12:29 PM, Coleen Phillimore wrote:
> Summary: Initialize host_klass while parsing the class with the other
> initializations.
>
> We really should initialize more fields in metadata constructors
> rather than outside them in parseClassFile but this is a smaller change.
>
> Tested with fast.vm.quick.testlist and java/lang/invoke tests and
> verified dacapo with VerifyBefore and AfterGC.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8039150/
> bug link https://bugs.openjdk.java.net/browse/JDK-8039150
>
>
> Thanks,
> Coleen
From coleen.phillimore at oracle.com Wed Jun 18 01:31:29 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 17 Jun 2014 21:31:29 -0400
Subject: RFR (xs) 8039150: host_klass invariant fails when verifying newly
loaded JSR-292 anonymous classes
In-Reply-To: <53A099FF.30106@oracle.com>
References: <53A09718.7070503@oracle.com> <53A099FF.30106@oracle.com>
Message-ID: <53A0EBF1.4050205@oracle.com>
Thanks Stefan and Serguei!
Coleen
On 6/17/14, 3:41 PM, serguei.spitsyn at oracle.com wrote:
> Coleen,
>
> It looks good to me.
>
> Thanks,
> Serguei
>
> On 6/17/14 12:29 PM, Coleen Phillimore wrote:
>> Summary: Initialize host_klass while parsing the class with the other
>> initializations.
>>
>> We really should initialize more fields in metadata constructors
>> rather than outside them in parseClassFile but this is a smaller change.
>>
>> Tested with fast.vm.quick.testlist and java/lang/invoke tests and
>> verified dacapo with VerifyBefore and AfterGC.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8039150/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8039150
>>
>>
>> Thanks,
>> Coleen
>
From david.holmes at oracle.com Wed Jun 18 01:55:46 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Jun 2014 11:55:46 +1000
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <53A092D4.3060100@oracle.com>
References: <53979E97.1040609@oracle.com>
<5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com>
<539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com>
<539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com>
<53A092D4.3060100@oracle.com>
Message-ID: <53A0F1A2.8000604@oracle.com>
On 18/06/2014 5:11 AM, Mikael Vidstedt wrote:
>
> New webrev here (only the hotspot part, the webrev for top hasn't changed):
>
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/
Looks okay to me.
>
> Comments inline.
Ditto
> On 2014-06-16 19:49, David Holmes wrote:
>> Hi Mikael,
>>
>> Sorry for the delay ...
>>
>> make/aix/makefiles/defs.make:
>>
>> This change doesn't make sense to me:
>>
>> 48 ifneq (,$(findstring $(ARCH), ppc))
>>
>> given that the logic immediately preceding this sets ARCH to either
>> ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow
>> for both 32-bit and 64-bit cross-builds but the earlier logic is
>> really precluding this. So it seems to me that the changes in this
>> file are completely unnecessary (or else the earlier logic also needs
>> changing).
>
> Indeed, that is correct - I missed the fact that ARCH is always
> overriden to be either ppc or ppc64. The old logic is unnecessarily hard
> to follow, but I guess that's in line with our hotspot Makefiles in
> general ;)
>
> I'll revert the changes to the file and add a mental note to self and
> others that linux appears to be the only platform where the incoming
> value of ARCH is actually honored - it's ignored/overridden on Solaris,
> BSD and AIX.
Note that it is honored on linux because that is the only platform which
currently supports true cross-compilation. If we supported
cross-compilation on the other platforms then they would need to honor
the incoming ARCH as meaning the ARCH for the target platform to build.
>> make/linux/makefiles/defs.make
>>
>> This block:
>>
>> 86 # i686/i586 and amd64/x86_64
>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
>> 88 ifeq ($(ARCH_DATA_MODEL), 64)
>> 89 ARCH_DATA_MODEL = 64
>> 90 MAKE_ARGS += LP64=1
>> 91 PLATFORM = linux-amd64
>> 92 VM_PLATFORM = linux_amd64
>> 93 HS_ARCH = x86
>> 94 else
>> 95 ARCH_DATA_MODEL = 32
>> 96 PLATFORM = linux-i586
>> 97 VM_PLATFORM = linux_i486
>> 98 HS_ARCH = x86
>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it
>> 100 ARCH = i686
>> 101 endif
>> 102 endif
>>
>> seems to allow the user to try and do a 64-bit build on a 32-bit build
>> machine. Not sure if that would get caught in an earlier sanity check?
>> (Same is true for the sparc block).
>
> While the changes are primarily just intended to cut down on the
> duplication I don't immediately see the reason why we wouldn't want to
> allow compiling a 64-bit VM from a 32-bit machine? We're cross compiling
> all sorts of platforms, so why not allow this if the compiler supports
> it? I'd prefer to keep it this way.
Ok. It is in theory at least possible to do this.
Cheers,
David
------
>> Also I don't think the following is actually true:
>>
>> # We have to reset ARCH to i686 since SRCARCH relies on it
>> ARCH = i686
>>
>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86
>> architecture designator will simply map to a SRCARCH of x86, as per
>> defs.make:
>>
>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm
>> ppc zero,$(ARCH)))
>> ARCH/ = x86
>> ARCH/sparc = sparc
>> ARCH/sparc64= sparc
>> ARCH/ia64 = ia64
>> ARCH/amd64 = x86
>> ARCH/x86_64 = x86
>> ARCH/ppc64 = ppc
>> ARCH/ppc = ppc
>> ARCH/arm = arm
>> ARCH/zero = zero
>
> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64,
> ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about
> cleaning that up before I sent out the first webrev, but soon found
> myself doing way more cleanup than was healthy for this specific change.
> However, since I had to update this change anyway I removed the ARCH
> reset part.
>
> Cheers,
> Mikael
>
>>
>>
>> Cheers,
>> David
>>
>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>>>
>>> Thanks Erik. Another review please?
>>>
>>> Cheers,
>>> Mikael
>>>
>>> On 2014-06-12 23:56, Erik Joelsson wrote:
>>>> Looks fine to me.
>>>>
>>>> /Erik
>>>>
>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>>>
>>>>> I have now verified that the changes work just fine for the platforms
>>>>> we build and test - both from the top level and when building hotspot
>>>>> only. Taking suggestions on other tests to perform. And it would be
>>>>> great if somebody could test the changes on on aix/ppc.
>>>>>
>>>>> So, kindly asking for "real"/final reviews of the changes:
>>>>>
>>>>> top:
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>
>>>>> hotspot:
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>>>
>>>>>> David,
>>>>>>
>>>>>> Thanks for the feedback. Essentially the logic in the
>>>>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>>>>> two different use cases:
>>>>>>
>>>>>> 1. ARCH being set by the JDK build system to the value of
>>>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>>>> typically from uname
>>>>>>
>>>>>> Since Solaris and bsd both override ARCH they do not care about
>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>>>
>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>>>> the hope that somebody can help out with that.
>>>>>>
>>>>>>
>>>>>> Summing it up, I have the following two webrevs:
>>>>>>
>>>>>> top:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>
>>>>>>
>>>>>> hotspot:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>
>>>>>>
>>>>>>
>>>>>> With these changes I can build the normal platforms, but more
>>>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>>>> feedback is much appreciated!
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>>>> Hi Mikael,
>>>>>>>
>>>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>>>
>>>>>>> As you note the main flow-on effect here is that the hotspot
>>>>>>> makefiles have to be updated for the cases where
>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>>>> only x86 has that issue.
>>>>>>>
>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>>>> both internally and in the build artifacts and bundles!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I need some feedback and comments on the below fix:
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>>>
>>>>>>>>
>>>>>>>> Background:
>>>>>>>>
>>>>>>>> When configuring the hotspot build the build system sets up the
>>>>>>>> ARCH
>>>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>>>> initialized
>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>>>> name. For
>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>>>>> The
>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>>>> gradually removed in favor of the other variables.
>>>>>>>>
>>>>>>>> Discussion:
>>>>>>>>
>>>>>>>> The two candidate variables to base ARCH on are as far as I can
>>>>>>>> tell
>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single,
>>>>>>>> well
>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }.
>>>>>>>> Together
>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>>>> ignored on
>>>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>>>
>>>>>>>> Before I go too far with this though I'd like to get some
>>>>>>>> feedback on
>>>>>>>> whether or not this is the right approach and what the exact value
>>>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>>>> system may
>>>>>>>> have to be updated for some platforms to support the new value(s).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikael
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
From dan at danny.cz Wed Jun 18 06:55:37 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Wed, 18 Jun 2014 08:55:37 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <539F22E0.2080202@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
<539AEA4D.8020204@oracle.com>
<20140613145531.559f6d943ef097550580a1f6@danny.cz>
<539E8F41.6070001@oracle.com>
<20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
<539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com>
<20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
<539F0CA0.3010309@oracle.com>
<20140616182920.baccf0cc83debbe522189688@danny.cz>
<539F22E0.2080202@oracle.com>
Message-ID: <20140618085537.0cc3e3e85856ae67c491c88e@danny.cz>
On Mon, 16 Jun 2014 19:01:20 +0200
Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> Hi Dan,
>
> I created a bug four this issue:
> https://bugs.openjdk.java.net/browse/JDK-8046938
> /Jesper
updated webrev is now at http://fedora.danny.cz/openjdk/size_t-2/webrev/
(and http://fedora.danny.cz/openjdk/size_t-2/webrev.zip)
changes:
- refreshed for current hs-gc repository
- dropped unnecessary typecast in get_hum_bytes() (concurrentMark.cpp)
- typecasts in FLAG_SET_ERGO() changed to uintx from size_t
(arguments.cpp)
With regards
Dan
> Dan Hor?k skrev 16/6/14 18:29:
> > On Mon, 16 Jun 2014 17:26:24 +0200
> > Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >
> >> Hi Dan,
> >>
> >> Since you got a comment from Bengt maybe you should fix that issue
> >> before I upload the new webrev.
> >>
> >> I looked through the webrev and I have one additional comment. I
> >> would prefer if the changes in arguments.cpp was the other way,
> >> casting stuff to uintx instead of size_t, since we use the result
> >> of MAX and MIN to set flags of type uintx.
> >
> > I wasn't sure what would be better approach here
> >
> >> When I applied the webrev a change in
> >> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp got in the
> >> way of the patch. The patch still applies but with an offset, so
> >> patch complains. If you build a new webrev with the changes above,
> >> also pull down the latest hs-gc to get the g1CollectedHeap.cpp
> >> change.
> >
> > thanks for the comments, I'll prepare new webrev hopefully tomorrow
> >
> >
> > Dan
> >
> >> Thanks!
> >> /Jesper
> >>
> >>
> >> Dan Hor?k skrev 16/6/14 16:21:
> >>> On Mon, 16 Jun 2014 16:19:17 +0200
> >>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>>
> >>>> Dan,
> >>>>
> >>>> I can host the webrev. Send me the zipped webrev archive and I'll
> >>>> upload it to cr.openjdk.
> >>>
> >>> Jesper, thanks a lot, the whole archive is at
> >>> http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
> >>>
> >>>
> >>> Dan
> >>>
> >>>> /Jesper
> >>>>
> >>>> David Holmes skrev 16/6/14 13:15:
> >>>>> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
> >>>>>> On Mon, 16 Jun 2014 16:31:29 +1000
> >>>>>> David Holmes <david.holmes at oracle.com> wrote:
> >>>>>>
> >>>>>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
> >>>>>>>> On Fri, 13 Jun 2014 14:10:53 +0200
> >>>>>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> >>>>>>>>> Then a formality comment. I think you have to post the
> >>>>>>>>> webrev on cr.openjdk.java.net to get the legal stuff
> >>>>>>>>> correct.
> >>>>>>>>
> >>>>>>>> hm, I've used this procedure (my webrev, then someone
> >>>>>>>> privileged takes it and pushes it) few times in the past and
> >>>>>>>> it worked.
> >>>>>>>
> >>>>>>> We've been advised that all contributions have to come in via
> >>>>>>> OpenJDK infrastructure - either a webrev on
> >>>>>>> cr.openjdk.java.net or as attachments to mailing list mails.
> >>>>>>
> >>>>>> I understand, but AFAIK cr.openjdk.java.net is accessible only
> >>>>>> to people with push access, which I'm not.
> >>>>>
> >>>>> No you only need Author status, not Committer.
> >>>>>
> >>>>>> So the question is will the list
> >>>>>> accept 3MB attachment? It is the size of the zipped webrev. Or
> >>>>>> will a plain text patch suffice?
> >>>>>
> >>>>> For large webrevs you may be able to find someone to host it for
> >>>>> you on cr.openjdk. I don't know what limit exists on the mailing
> >>>>> list but I'd hate to see very large patches submitted that way.
> >>>>>
> >>>>> Cheers,
> >>>>> David
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>> David
> >>>>>>> -----
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Dan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Bengt
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
> >>>>>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
> >>>>>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> Which repository is the patch built on? Since it is mostly
> >>>>>>>>>>> GC code it would be good if it goes in through jdk9/hs-gc.
> >>>>>>>>>>>
> >>>>>>>>>>> The changes looks good in the webrev, but the patch did
> >>>>>>>>>>> not apply to a recent jdk9/hs-gc. Especially the collector
> >>>>>>>>>>> policy code has changed a lot recently.
> >>>>>>>>>>>
> >>>>>>>>>>> I would prefer to look at the changes applied in my
> >>>>>>>>>>> workspace before approving it, so if you could update to a
> >>>>>>>>>>> recent hs-gc it would be great.
> >>>>>>>>>> I have refreshed the patch for the hs-gc repository, please
> >>>>>>>>>> see http://fedora.danny.cz/openjdk/size_t-1/webrev/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Dan
> >>>>>>>>>>
> >>>>>>>>>>> Thanks!
> >>>>>>>>>>> /Jesper
> >>>>>>>>>>>
> >>>>>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
> >>>>>>>>>>>> Thank you, Dan
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think casting is acceptable solution. Someone in GC
> >>>>>>>>>>>> group should review and sponsor this since you touched
> >>>>>>>>>>>> GC code mostly.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards,
> >>>>>>>>>>>> Vladimir
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> this the last and largest part of my changes required on
> >>>>>>>>>>>>> s390 (32-bit) to build OpenJDK out of the box. The
> >>>>>>>>>>>>> MIN2/MAX2 functions are implemented using templates and
> >>>>>>>>>>>>> require both arguments to be of the same type. This is a
> >>>>>>>>>>>>> problem when one parameter is of size_t type and the
> >>>>>>>>>>>>> second of uintx type and the platform has size_t defined
> >>>>>>>>>>>>> as eg. unsigned long as on s390 (32-bit).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As a solution [1] I chose to typecast the smaller type
> >>>>>>>>>>>>> (uintx) to size_t which is of same or larger size.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I
> >>>>>>>>>>>>> should be covered by Red Hat's CLA for my contributions.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> With regards
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>
> >>>>>>>>>
From erik.joelsson at oracle.com Wed Jun 18 08:14:02 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 18 Jun 2014 10:14:02 +0200
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <53A092D4.3060100@oracle.com>
References: <53979E97.1040609@oracle.com>
<5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com>
<539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com>
<539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com>
<53A092D4.3060100@oracle.com>
Message-ID: <53A14A4A.5090208@oracle.com>
Looks ok to me.
/Erik
On 2014-06-17 21:11, Mikael Vidstedt wrote:
>
> New webrev here (only the hotspot part, the webrev for top hasn't
> changed):
>
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/
>
>
> Comments inline.
>
> On 2014-06-16 19:49, David Holmes wrote:
>> Hi Mikael,
>>
>> Sorry for the delay ...
>>
>> make/aix/makefiles/defs.make:
>>
>> This change doesn't make sense to me:
>>
>> 48 ifneq (,$(findstring $(ARCH), ppc))
>>
>> given that the logic immediately preceding this sets ARCH to either
>> ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow
>> for both 32-bit and 64-bit cross-builds but the earlier logic is
>> really precluding this. So it seems to me that the changes in this
>> file are completely unnecessary (or else the earlier logic also needs
>> changing).
>
> Indeed, that is correct - I missed the fact that ARCH is always
> overriden to be either ppc or ppc64. The old logic is unnecessarily
> hard to follow, but I guess that's in line with our hotspot Makefiles
> in general ;)
>
> I'll revert the changes to the file and add a mental note to self and
> others that linux appears to be the only platform where the incoming
> value of ARCH is actually honored - it's ignored/overridden on
> Solaris, BSD and AIX.
>
>> make/linux/makefiles/defs.make
>>
>> This block:
>>
>> 86 # i686/i586 and amd64/x86_64
>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
>> 88 ifeq ($(ARCH_DATA_MODEL), 64)
>> 89 ARCH_DATA_MODEL = 64
>> 90 MAKE_ARGS += LP64=1
>> 91 PLATFORM = linux-amd64
>> 92 VM_PLATFORM = linux_amd64
>> 93 HS_ARCH = x86
>> 94 else
>> 95 ARCH_DATA_MODEL = 32
>> 96 PLATFORM = linux-i586
>> 97 VM_PLATFORM = linux_i486
>> 98 HS_ARCH = x86
>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it
>> 100 ARCH = i686
>> 101 endif
>> 102 endif
>>
>> seems to allow the user to try and do a 64-bit build on a 32-bit
>> build machine. Not sure if that would get caught in an earlier sanity
>> check? (Same is true for the sparc block).
>
> While the changes are primarily just intended to cut down on the
> duplication I don't immediately see the reason why we wouldn't want to
> allow compiling a 64-bit VM from a 32-bit machine? We're cross
> compiling all sorts of platforms, so why not allow this if the
> compiler supports it? I'd prefer to keep it this way.
>
>> Also I don't think the following is actually true:
>>
>> # We have to reset ARCH to i686 since SRCARCH relies on it
>> ARCH = i686
>>
>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86
>> architecture designator will simply map to a SRCARCH of x86, as per
>> defs.make:
>>
>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm
>> ppc zero,$(ARCH)))
>> ARCH/ = x86
>> ARCH/sparc = sparc
>> ARCH/sparc64= sparc
>> ARCH/ia64 = ia64
>> ARCH/amd64 = x86
>> ARCH/x86_64 = x86
>> ARCH/ppc64 = ppc
>> ARCH/ppc = ppc
>> ARCH/arm = arm
>> ARCH/zero = zero
>
> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64,
> ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about
> cleaning that up before I sent out the first webrev, but soon found
> myself doing way more cleanup than was healthy for this specific
> change. However, since I had to update this change anyway I removed
> the ARCH reset part.
>
> Cheers,
> Mikael
>
>>
>>
>> Cheers,
>> David
>>
>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>>>
>>> Thanks Erik. Another review please?
>>>
>>> Cheers,
>>> Mikael
>>>
>>> On 2014-06-12 23:56, Erik Joelsson wrote:
>>>> Looks fine to me.
>>>>
>>>> /Erik
>>>>
>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>>>
>>>>> I have now verified that the changes work just fine for the platforms
>>>>> we build and test - both from the top level and when building hotspot
>>>>> only. Taking suggestions on other tests to perform. And it would be
>>>>> great if somebody could test the changes on on aix/ppc.
>>>>>
>>>>> So, kindly asking for "real"/final reviews of the changes:
>>>>>
>>>>> top:
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>
>>>>> hotspot:
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>>>
>>>>>> David,
>>>>>>
>>>>>> Thanks for the feedback. Essentially the logic in the
>>>>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>>>>> two different use cases:
>>>>>>
>>>>>> 1. ARCH being set by the JDK build system to the value of
>>>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>>>> typically from uname
>>>>>>
>>>>>> Since Solaris and bsd both override ARCH they do not care about
>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>>>
>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>>>> the hope that somebody can help out with that.
>>>>>>
>>>>>>
>>>>>> Summing it up, I have the following two webrevs:
>>>>>>
>>>>>> top:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>
>>>>>>
>>>>>> hotspot:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>
>>>>>>
>>>>>>
>>>>>> With these changes I can build the normal platforms, but more
>>>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>>>> feedback is much appreciated!
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>>>> Hi Mikael,
>>>>>>>
>>>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>>>
>>>>>>> As you note the main flow-on effect here is that the hotspot
>>>>>>> makefiles have to be updated for the cases where
>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>>>> only x86 has that issue.
>>>>>>>
>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>>>> both internally and in the build artifacts and bundles!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I need some feedback and comments on the below fix:
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>>>
>>>>>>>>
>>>>>>>> Background:
>>>>>>>>
>>>>>>>> When configuring the hotspot build the build system sets up the
>>>>>>>> ARCH
>>>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>>>> initialized
>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>>>> name. For
>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>>>>> The
>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>>>> gradually removed in favor of the other variables.
>>>>>>>>
>>>>>>>> Discussion:
>>>>>>>>
>>>>>>>> The two candidate variables to base ARCH on are as far as I can
>>>>>>>> tell
>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a
>>>>>>>> single, well
>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }.
>>>>>>>> Together
>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for
>>>>>>>> the
>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>>>> ignored on
>>>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>>>
>>>>>>>> Before I go too far with this though I'd like to get some
>>>>>>>> feedback on
>>>>>>>> whether or not this is the right approach and what the exact value
>>>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>>>> system may
>>>>>>>> have to be updated for some platforms to support the new value(s).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikael
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
From lev.priima at oracle.com Wed Jun 18 10:34:53 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 18 Jun 2014 14:34:53 +0400
Subject: RFR: 8041794: remove bytecodes_<arch>.{cpp,hpp} files
In-Reply-To: <CDA9A18E-862B-49B2-857D-C5452811C340@oracle.com>
References: <53A067E9.2070800@oracle.com>
<CDA9A18E-862B-49B2-857D-C5452811C340@oracle.com>
Message-ID: <53A16B4D.8040405@oracle.com>
Thanks Coleen and Christian !
Lev
On 06/17/2014 09:37 PM, Christian Thalinger wrote:
> Looks good. Thanks for picking that one up.
>
> On Jun 17, 2014, at 9:08 AM, Lev Priima <lev.priima at oracle.com> wrote:
>
>> Hi,
>>
>> Problem:
>> We don't have any platform specific bytecodes and these files are empty:
>> hs-comp/hotspot$ find -name bytecodes_\* | grep -v "/.hg/"
>> ./src/cpu/ppc/vm/bytecodes_ppc.cpp
>> ./src/cpu/ppc/vm/bytecodes_ppc.hpp
>> ./src/cpu/sparc/vm/bytecodes_sparc.cpp
>> ./src/cpu/sparc/vm/bytecodes_sparc.hpp
>> ./src/cpu/x86/vm/bytecodes_x86.cpp
>> ./src/cpu/x86/vm/bytecodes_x86.hpp
>> ./src/cpu/zero/vm/bytecodes_zero.cpp
>> ./src/cpu/zero/vm/bytecodes_zero.hpp
>>
>> .hpp's are only included in bytecodes.hpp:
>> hs-comp/hotspot$ grep -rn \"bytecodes_\* src
>> src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/Parser.java:79: public static final String BYTECODES_ELEMENT = "bytecodes";
>> src/share/vm/interpreter/bytecodes.hpp:292:# include "bytecodes_x86.hpp"
>> src/share/vm/interpreter/bytecodes.hpp:295:# include "bytecodes_sparc.hpp"
>> src/share/vm/interpreter/bytecodes.hpp:298:# include "bytecodes_zero.hpp"
>> src/share/vm/interpreter/bytecodes.hpp:301:# include "bytecodes_arm.hpp"
>> src/share/vm/interpreter/bytecodes.hpp:304:# include "bytecodes_ppc.hpp"
>>
>> All bytecodes_<arch>.cpp files have empty implementations of their functions.
>> Function:
>> src/share/vm/interpreter/bytecodes.hpp:335: static Code pd_base_code_for(Code code);
>> with empty implementation in each platform-specific bytecodes_* file is never called.
>>
>>
>> Solution:
>> I've removed these files and include directives of them. Also I removed two function declarations and one call-statement of pd_initialize().
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8041794
>>
>> Webrev:
>> http://cr.openjdk.java.net/~iignatyev/lpriima/8041794/webrev.00/
>>
>> Testing:
>> Jprt build and tests
>>
>> --
>> Lev
>>
From fweimer at redhat.com Wed Jun 18 11:27:10 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 18 Jun 2014 13:27:10 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
Message-ID: <53A1778E.2040400@redhat.com>
On 06/12/2014 11:05 AM, Dan Hor?k wrote:
> this the last and largest part of my changes required on s390 (32-bit)
> to build OpenJDK out of the box. The MIN2/MAX2 functions are implemented
> using templates and require both arguments to be of the same type.
Would it make sense to compute a suitable common type at compile time
instead, and change the return type to that? That would avoid adding
all these casts, which might well obscure other problems.
--
Florian Weimer / Red Hat Product Security Team
From jesper.wilhelmsson at oracle.com Wed Jun 18 12:47:12 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Wed, 18 Jun 2014 14:47:12 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140618085537.0cc3e3e85856ae67c491c88e@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com> <20140613095511.5fae7c4b483bb65f073e5628@danny.cz> <539AEA4D.8020204@oracle.com> <20140613145531.559f6d943ef097550580a1f6@danny.cz> <539E8F41.6070001@oracle.com> <20140616091702.28b895ce918bdf4c58d2506f@danny.cz> <539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com> <20140616162130.ac9bec274c625241bb7fd18d@danny.cz> <539F0CA0.3010309@oracle.com> <20140616182920.baccf0cc83debbe522189688@danny.cz> <539F22E0.2080202@oracle.com>
<20140618085537.0cc3e3e85856ae67c491c88e@danny.cz>
Message-ID: <53A18A50.50001@oracle.com>
Hi Dan,
I have uploaded your webrev here:
http://cr.openjdk.java.net/~jwilhelm/8046938/webrev/
The change looks good to me.
/Jesper
Dan Hor?k skrev 18/6/14 08:55:
> On Mon, 16 Jun 2014 19:01:20 +0200
> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>
>> Hi Dan,
>>
>> I created a bug four this issue:
>> https://bugs.openjdk.java.net/browse/JDK-8046938
>> /Jesper
>
> updated webrev is now at http://fedora.danny.cz/openjdk/size_t-2/webrev/
> (and http://fedora.danny.cz/openjdk/size_t-2/webrev.zip)
>
> changes:
> - refreshed for current hs-gc repository
> - dropped unnecessary typecast in get_hum_bytes() (concurrentMark.cpp)
> - typecasts in FLAG_SET_ERGO() changed to uintx from size_t
> (arguments.cpp)
>
>
> With regards
>
> Dan
>
>> Dan Hor?k skrev 16/6/14 18:29:
>>> On Mon, 16 Jun 2014 17:26:24 +0200
>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> Since you got a comment from Bengt maybe you should fix that issue
>>>> before I upload the new webrev.
>>>>
>>>> I looked through the webrev and I have one additional comment. I
>>>> would prefer if the changes in arguments.cpp was the other way,
>>>> casting stuff to uintx instead of size_t, since we use the result
>>>> of MAX and MIN to set flags of type uintx.
>>>
>>> I wasn't sure what would be better approach here
>>>
>>>> When I applied the webrev a change in
>>>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp got in the
>>>> way of the patch. The patch still applies but with an offset, so
>>>> patch complains. If you build a new webrev with the changes above,
>>>> also pull down the latest hs-gc to get the g1CollectedHeap.cpp
>>>> change.
>>>
>>> thanks for the comments, I'll prepare new webrev hopefully tomorrow
>>>
>>>
>>> Dan
>>>
>>>> Thanks!
>>>> /Jesper
>>>>
>>>>
>>>> Dan Hor?k skrev 16/6/14 16:21:
>>>>> On Mon, 16 Jun 2014 16:19:17 +0200
>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>
>>>>>> Dan,
>>>>>>
>>>>>> I can host the webrev. Send me the zipped webrev archive and I'll
>>>>>> upload it to cr.openjdk.
>>>>>
>>>>> Jesper, thanks a lot, the whole archive is at
>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
>>>>>
>>>>>
>>>>> Dan
>>>>>
>>>>>> /Jesper
>>>>>>
>>>>>> David Holmes skrev 16/6/14 13:15:
>>>>>>> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
>>>>>>>> On Mon, 16 Jun 2014 16:31:29 +1000
>>>>>>>> David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
>>>>>>>>>> On Fri, 13 Jun 2014 14:10:53 +0200
>>>>>>>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>>>>>>>>>> Then a formality comment. I think you have to post the
>>>>>>>>>>> webrev on cr.openjdk.java.net to get the legal stuff
>>>>>>>>>>> correct.
>>>>>>>>>>
>>>>>>>>>> hm, I've used this procedure (my webrev, then someone
>>>>>>>>>> privileged takes it and pushes it) few times in the past and
>>>>>>>>>> it worked.
>>>>>>>>>
>>>>>>>>> We've been advised that all contributions have to come in via
>>>>>>>>> OpenJDK infrastructure - either a webrev on
>>>>>>>>> cr.openjdk.java.net or as attachments to mailing list mails.
>>>>>>>>
>>>>>>>> I understand, but AFAIK cr.openjdk.java.net is accessible only
>>>>>>>> to people with push access, which I'm not.
>>>>>>>
>>>>>>> No you only need Author status, not Committer.
>>>>>>>
>>>>>>>> So the question is will the list
>>>>>>>> accept 3MB attachment? It is the size of the zipped webrev. Or
>>>>>>>> will a plain text patch suffice?
>>>>>>>
>>>>>>> For large webrevs you may be able to find someone to host it for
>>>>>>> you on cr.openjdk. I don't know what limit exists on the mailing
>>>>>>> list but I'd hate to see very large patches submitted that way.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Bengt
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
>>>>>>>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
>>>>>>>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which repository is the patch built on? Since it is mostly
>>>>>>>>>>>>> GC code it would be good if it goes in through jdk9/hs-gc.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The changes looks good in the webrev, but the patch did
>>>>>>>>>>>>> not apply to a recent jdk9/hs-gc. Especially the collector
>>>>>>>>>>>>> policy code has changed a lot recently.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would prefer to look at the changes applied in my
>>>>>>>>>>>>> workspace before approving it, so if you could update to a
>>>>>>>>>>>>> recent hs-gc it would be great.
>>>>>>>>>>>> I have refreshed the patch for the hs-gc repository, please
>>>>>>>>>>>> see http://fedora.danny.cz/openjdk/size_t-1/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
>>>>>>>>>>>>>> Thank you, Dan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think casting is acceptable solution. Someone in GC
>>>>>>>>>>>>>> group should review and sponsor this since you touched
>>>>>>>>>>>>>> GC code mostly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> this the last and largest part of my changes required on
>>>>>>>>>>>>>>> s390 (32-bit) to build OpenJDK out of the box. The
>>>>>>>>>>>>>>> MIN2/MAX2 functions are implemented using templates and
>>>>>>>>>>>>>>> require both arguments to be of the same type. This is a
>>>>>>>>>>>>>>> problem when one parameter is of size_t type and the
>>>>>>>>>>>>>>> second of uintx type and the platform has size_t defined
>>>>>>>>>>>>>>> as eg. unsigned long as on s390 (32-bit).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As a solution [1] I chose to typecast the smaller type
>>>>>>>>>>>>>>> (uintx) to size_t which is of same or larger size.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I
>>>>>>>>>>>>>>> should be covered by Red Hat's CLA for my contributions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With regards
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>
>>>>>>>>>>>
From jon.masamitsu at oracle.com Wed Jun 18 16:25:18 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 18 Jun 2014 09:25:18 -0700
Subject: RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected
heap size on sparcv9
In-Reply-To: <536BA420.5000408@oracle.com>
References: <5368A0D6.5050609@oracle.com> <5368C396.4020206@oracle.com>
<536BA420.5000408@oracle.com>
Message-ID: <53A1BD6E.2030708@oracle.com>
On 05/08/2014 08:34 AM, Erik Helin wrote:
> Hi Stefan,
>
> thanks for your thorough review! Please see new webrev at:
> http://cr.openjdk.java.net/~ehelin/8027915/webrev.01/
>
> and incremental webrev at:
> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00-01/
Looks good.
Reviewed.
Jon
>
> and comments inline!
>
> On 2014-05-06 13:12, Stefan Johansson wrote:
>> Hi Erik,
>>
>> Thanks for making page_size_for_region more strict. A few comments:
>>
>> src/share/vm/runtime/os.cpp
>>
>> With this fix page_size_for_region doesn't care about alignment at all
>> (old version wasn't much better) and to me that feels wrong. I would
>> expect to get a page size that the given region sizes is aligned to, but
>> I might be missing some use case where that isn't needed.
>
> Agree, page_size_for_region should check alignment for large pages.
> Added fix and regression tests.
>
> On 2014-05-06 13:12, Stefan Johansson wrote:
>> src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
>>
>> For the heap we want both min and max to be a multiple of the page size
>> so we shoud call page_size_for_region for both _min_heap_byte_size and
>> _max_heap_byte_size and use the smallest of the two returned page sizes.
>
> Agree, fixed.
>
> On 2014-05-06 13:12, Stefan Johansson wrote:
>> src/share/vm/memory/heap.cpp
>>
>> The current patch will not change the default behavior so I'm fine with
>> just calling page_size_for_region once using reserved_size, but someone
>> with more insight might know if we should handle it the same way as the
>> generationSizer and use both committed and reserved.
>
> Since I'm not sure how the compiler guys want to handle this, I opted
> for the safe alternative and updated the patch to be backwards
> compatible with the old code (except slightly more strict).
>
> Thanks,
> Erik
>
>> Thanks,
>> Stefan
>>
>>
>> On 2014-05-06 10:44, Erik Helin wrote:
>>> Hi all,
>>>
>>> this patch changes
>>> os::page_size_for_region(min_size, max_size, min_pages) to always
>>> guarantee that the returned page size <= max_size / min_pages. Prior
>>> to this patch, page_size_for_region could return a page size larger
>>> than max_size / min_pages. This can cause some unexpected behavior
>>> for code using page_size_for_region, such as the following regression
>>> tests:
>>>
>>> http://cr.openjdk.java.net/~ehelin/8027915/regression-test/
>>>
>>> As the test shows, if you have a 2 MB region and you must use at least
>>> 2 pages, you would still get back 2 MB as the page size on a Linux
>>> machine that supports 2 MB large pages. The reason for this is
>>> explained in a comment above the function in os.hpp:
>>>
>>> // The current implementation ignores min_pages if a larger page
>>> // size is an exact multiple of both region_min_size and
>>> // region_max_size. This allows larger pages to be used when doing
>>> // so would not cause fragmentation; in particular, a single page can
>>> // be used when region_min_size == region_max_size == a supported page
>>> // size.
>>>
>>> Reducing fragmentation of large pages is good but the varying return
>>> value makes it very hard to depend on os::page_size_for_region in
>>> calculations (for example when sizing the heap).
>>>
>>> This patch removes the fragmentation prevention mechanism, simplifies
>>> the function and adds a regression tests:
>>>
>>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00/
>>>
>>> Testing:
>>> - JPRT
>>>
>>> Thanks,
>>> Erik
>>
From mandy.chung at oracle.com Wed Jun 18 18:16:33 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Jun 2014 11:16:33 -0700
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <539FD28B.7000201@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com>
Message-ID: <53A1D781.7070704@oracle.com>
Hi Coleen,
I'm glad to see this change to go in. Thanks for doing this. The jdk
change looks good. Minor comment:
684 // Initialized in JVM not by fake constructor
685 private final ClassLoader classLoader;
I prefer to say "Initialized in JVM not by the private constructor"
and the comment of the private constructor perhaps can say:
/*
* Private constructor.Only the Java Virtual Machine creates Class
* objects. This constructor is not used and JVM directly injects
* value of the instance fields.
*/
private Class(ClassLoader loader) {
classLoader = loader;
}
And It may be worth to mention that the classLoader field is initialized to
the given loader parameter instead of null to prepare for possible future JIT optimization.
I didn't review the hotspot change. The new classLoader field is not
in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized
jdk/hotspot change? What if you push both changes through the same forest jdk9/hs-rt?
A side note - Christian has a patch attached in this bug that can
improve the performance when running with SecurityManager on the
classloader related check for permission. Can you create a new
bug to track that so that it won't get lost once this bug is
resolved?
thanks
Mandy
On 6/16/2014 10:30 PM, David Holmes wrote:
> On 17/06/2014 6:43 AM, Coleen Phillimore wrote:
>>
>>
>> /*
>> * Constructor. Only the Java Virtual Machine creates Class
>> * objects, but this constructor prevents a warning that
>> classLoader is not
>> * initialized.
>> */
>> private Class(ClassLoader loader) {
>> classLoader = loader;
>> }
>
> Why not just initialize classloader to null when it is declared and
> leave the constructor alone? The constructor exists to prevent javac
> from creating a default constructor, and thus ensuring Class instances
> can not be created (which is what the original comment should, but
> doesn't quite, say).
>
> David
>
>> Coleen
>>>
>>> Roger
>>>
>>> On 6/16/2014 1:45 PM, Lois Foltan wrote:
>>>> Hi Coleen,
>>>> This looks good.
>>>> Lois
>>>>
>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote:
>>>>> Summary: Add classLoader to java/lang/Class instance for fast access
>>>>>
>>>>> In order to improve performance of Class.getClassLoader() in a way
>>>>> to allow the compilers to automatically optimize this call, I added
>>>>> the classLoader to the instance of java/lang/Class. For
>>>>> microbenchmarks, this results in a 98% improvement, which was
>>>>> expected. For Oracle internal applications, this results in a
>>>>> 10-12% improvement on solaris/sparc. The increase in size of
>>>>> java/lang/Class can be offset by other changes (removing constant
>>>>> pool lock, or removing signers).
>>>>>
>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>>>>> associated linked bugs for more details.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>>>>
>>>>> There is both hotspot and jdk changes for this change. The hotspot
>>>>> changes can work without the jdk changes (check for optional field),
>>>>> but not vice-versa. I'll file another bug (and compatibility
>>>>> request) to remove JVM_GetClassLoader from hotspot.
>>>>>
>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk
>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>>
>>>>
>>>
>>
From coleen.phillimore at oracle.com Wed Jun 18 18:35:33 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Jun 2014 14:35:33 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A1D781.7070704@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com>
Message-ID: <53A1DBF5.2090607@oracle.com>
Mandy,
Thanks for looking at this.
On 6/18/14, 2:16 PM, Mandy Chung wrote:
> Hi Coleen,
>
> I'm glad to see this change to go in. Thanks for doing this. The jdk
> change looks good. Minor comment:
>
> 684 // Initialized in JVM not by fake constructor
> 685 private final ClassLoader classLoader;
>
> I prefer to say "Initialized in JVM not by the private constructor"
Okay. I made this change.
> and the comment of the private constructor perhaps can say:
>
> /*
> * Private constructor.Only the Java Virtual Machine creates Class
> * objects. This constructor is not used and JVM directly injects
> * value of the instance fields.
> */
> private Class(ClassLoader loader) {
> classLoader = loader;
> }
>
> And It may be worth to mention that the classLoader field is
> initialized to
> the given loader parameter instead of null to prepare for possible
> future JIT optimization.
How about (see below about injected fields):
/*
* Private constructor. Only the Java Virtual Machine creates Class
* objects. This constructor is not used but prevents a warning that
* classLoader is not initialized. The initialization value of
non-null
* prevents future JIT optimizations from assuming this final field
is null.
*/
>
> I didn't review the hotspot change. The new classLoader field is not
> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized
> jdk/hotspot change? What if you push both changes through the same
> forest jdk9/hs-rt?
The new field classLoader is explicit and not injected by the jvm. The
jvm looks up the offset of the field when it lays out the class Class
and initializes it directly in the instance of java.lang.Class. So it
isn't added to the injected fields.
>
> A side note - Christian has a patch attached in this bug that can
> improve the performance when running with SecurityManager on the
> classloader related check for permission. Can you create a new
> bug to track that so that it won't get lost once this bug is
> resolved?
I didn't completely follow the relationship between Chris's patch and
this bug. Yes, I'll file a new bug or ask someone who knows more about
it to do so.
Thanks!
Coleen
>
> thanks
> Mandy
>
> On 6/16/2014 10:30 PM, David Holmes wrote:
>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote:
>>>
>>>
>>> /*
>>> * Constructor. Only the Java Virtual Machine creates Class
>>> * objects, but this constructor prevents a warning that
>>> classLoader is not
>>> * initialized.
>>> */
>>> private Class(ClassLoader loader) {
>>> classLoader = loader;
>>> }
>>
>> Why not just initialize classloader to null when it is declared and
>> leave the constructor alone? The constructor exists to prevent javac
>> from creating a default constructor, and thus ensuring Class
>> instances can not be created (which is what the original comment
>> should, but doesn't quite, say).
>>
>> David
>>
>>> Coleen
>>>>
>>>> Roger
>>>>
>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote:
>>>>> Hi Coleen,
>>>>> This looks good.
>>>>> Lois
>>>>>
>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote:
>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access
>>>>>>
>>>>>> In order to improve performance of Class.getClassLoader() in a way
>>>>>> to allow the compilers to automatically optimize this call, I added
>>>>>> the classLoader to the instance of java/lang/Class. For
>>>>>> microbenchmarks, this results in a 98% improvement, which was
>>>>>> expected. For Oracle internal applications, this results in a
>>>>>> 10-12% improvement on solaris/sparc. The increase in size of
>>>>>> java/lang/Class can be offset by other changes (removing constant
>>>>>> pool lock, or removing signers).
>>>>>>
>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>>>>>> associated linked bugs for more details.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>>>>>
>>>>>> There is both hotspot and jdk changes for this change. The hotspot
>>>>>> changes can work without the jdk changes (check for optional field),
>>>>>> but not vice-versa. I'll file another bug (and compatibility
>>>>>> request) to remove JVM_GetClassLoader from hotspot.
>>>>>>
>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk
>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
From coleen.phillimore at oracle.com Wed Jun 18 18:37:25 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Jun 2014 14:37:25 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A1D781.7070704@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com>
Message-ID: <53A1DC65.1020304@oracle.com>
Hi, I missed a question.
On 6/18/14, 2:16 PM, Mandy Chung wrote:
> Hi Coleen,
>
> I'm glad to see this change to go in. Thanks for doing this. The jdk
> change looks good. Minor comment:
>
> 684 // Initialized in JVM not by fake constructor
> 685 private final ClassLoader classLoader;
>
> I prefer to say "Initialized in JVM not by the private constructor"
> and the comment of the private constructor perhaps can say:
>
> /*
> * Private constructor.Only the Java Virtual Machine creates Class
> * objects. This constructor is not used and JVM directly injects
> * value of the instance fields.
> */
> private Class(ClassLoader loader) {
> classLoader = loader;
> }
>
> And It may be worth to mention that the classLoader field is
> initialized to
> the given loader parameter instead of null to prepare for possible
> future JIT optimization.
>
> I didn't review the hotspot change. The new classLoader field is not
> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized
> jdk/hotspot change? What if you push both changes through the same
> forest jdk9/hs-rt?
The plan is to push both through hs-rt. The jdk changes don't work
without the jvm changes but I think that's fine because both will hit
jdk9/dev at the same time. I've prewarned the gatekeepers and
Alejandro. The hotspot change works without the jdk change because most
people on hotspot don't build full jdks during development (yet).
Thanks,
Coleen
>
> A side note - Christian has a patch attached in this bug that can
> improve the performance when running with SecurityManager on the
> classloader related check for permission. Can you create a new
> bug to track that so that it won't get lost once this bug is
> resolved?
>
> thanks
> Mandy
>
> On 6/16/2014 10:30 PM, David Holmes wrote:
>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote:
>>>
>>>
>>> /*
>>> * Constructor. Only the Java Virtual Machine creates Class
>>> * objects, but this constructor prevents a warning that
>>> classLoader is not
>>> * initialized.
>>> */
>>> private Class(ClassLoader loader) {
>>> classLoader = loader;
>>> }
>>
>> Why not just initialize classloader to null when it is declared and
>> leave the constructor alone? The constructor exists to prevent javac
>> from creating a default constructor, and thus ensuring Class
>> instances can not be created (which is what the original comment
>> should, but doesn't quite, say).
>>
>> David
>>
>>> Coleen
>>>>
>>>> Roger
>>>>
>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote:
>>>>> Hi Coleen,
>>>>> This looks good.
>>>>> Lois
>>>>>
>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote:
>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access
>>>>>>
>>>>>> In order to improve performance of Class.getClassLoader() in a way
>>>>>> to allow the compilers to automatically optimize this call, I added
>>>>>> the classLoader to the instance of java/lang/Class. For
>>>>>> microbenchmarks, this results in a 98% improvement, which was
>>>>>> expected. For Oracle internal applications, this results in a
>>>>>> 10-12% improvement on solaris/sparc. The increase in size of
>>>>>> java/lang/Class can be offset by other changes (removing constant
>>>>>> pool lock, or removing signers).
>>>>>>
>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>>>>>> associated linked bugs for more details.
>>>>>>
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>>>>>
>>>>>> There is both hotspot and jdk changes for this change. The hotspot
>>>>>> changes can work without the jdk changes (check for optional field),
>>>>>> but not vice-versa. I'll file another bug (and compatibility
>>>>>> request) to remove JVM_GetClassLoader from hotspot.
>>>>>>
>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk
>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
From coleen.phillimore at oracle.com Wed Jun 18 18:47:21 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Jun 2014 14:47:21 -0400
Subject: RFR (M) 8026977: NPG: Remove ConstantPool::lock
In-Reply-To: <8512167.xIYu4dz7Hb@mgerdin03>
References: <5398C681.70209@oracle.com> <539E9274.9070300@oracle.com>
<539F0150.10508@oracle.com> <8512167.xIYu4dz7Hb@mgerdin03>
Message-ID: <53A1DEB9.7000802@oracle.com>
RFE filed https://bugs.openjdk.java.net/browse/JDK-8047290
thanks,
Coleen
On 6/17/14, 6:11 AM, Mikael Gerdin wrote:
> On Monday 16 June 2014 10.38.08 Coleen Phillimore wrote:
>> On 6/16/14, 2:45 AM, David Holmes wrote:
>>> On 13/06/2014 6:58 AM, Coleen Phillimore wrote:
>>>> Thank you, John! Christian suggested I take out ConstantPool::lock()
>>>> and while doing so I discovered I was still using the unsafe
>>>> ConstantPool::unresolved_klass_at() call. So I replaced these with
>>>> ConstantPool::klass_name_at() which is safe.
>>>>
>>>> Also, Sergey Kuksenko's tests exposed a deadlock with this code. Locking
>>>> the metaspace_lock() must not check for safepoints.
>>> Just to be paranoid ... so all user's of this lock elide the safepoint
>>> check, and no use of this lock can encounter a safepoint within the
>>> locked region?
>> Yes, to first question and I'm not sure to second. I believe we can
>> have a metaspace lock and call GC. The reason it's a no-safepoint-check
>> lock is that it can be taken during GC. Which sounds unnervingly
>> circular. I'll have to reconstruct why this lock was done this way.
>>
>> I wish there was a consistency check though. If you take a lock without
>> checking for safepoint, we should give an assertion if you take the same
>> lock and check for safepoint. Not sure if there's an easy way to code
>> it, but I think it would be worth having.
> Can't we use the type system for this?
>
> Have a
> class NoSafepointCheckMutex which always elides safepoint checks
> and a
> class Mutex which does not allow elision of safepoint checks.
>
> /Mikael
>
>> Coleen
>>
>>> David
>>> -----
>>>
>>>> I make Chris's changes and fixed these problems and retested. Most
>>>> files are unchanged, but here is the updated webrev.
>>>>
>>>> I didn't mention before that this change saves 152 bytes per class.
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/8026977_2/
>>>>
>>>> Thanks!
>>>> Coleen
>>>>
>>>> On 6/12/14, 12:57 PM, John Rose wrote:
>>>>> Reviewed. This is a good change. The code is much cleaner. Thanks.
>>>>> ? John
>>>>>
>>>>> On Jun 12, 2014, at 8:57 AM, Coleen Phillimore
>>>>>
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> On 6/12/14, 11:43 AM, Christian Thalinger wrote:
>>>>>>> +Mutex* ConstantPool::lock() {
>>>>>>> + // Use the lock from the metaspace in the rare instance we need
>>>>>>> to lock the entries
>>>>>>> + // in this cpool or its associated cache. Only used for setting
>>>>>>> invokedynamic cpCache
>>>>>>> + // entry.
>>>>>>> + return pool_holder()->class_loader_data()->metaspace_lock();
>>>>>>> +}
>>>>>>>
>>>>>>> I?d rather see this method removed completely and use the metaspace
>>>>>>> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
>>>>>>> Otherwise it's confusing.
>>>>>> Ok, I can change that.
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>>> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
>>>>>>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>> Summary: Write klass and resolved_references constant pool fields
>>>>>>>> lock free.
>>>>>>>>
>>>>>>>> The constant pool values that can change were already read lock
>>>>>>>> free, through the cpSlot type (lsb set for Symbol vs. Klass) for
>>>>>>>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the
>>>>>>>> other values that can change were moved to the resolved_references
>>>>>>>> array, which is initialized to null. Non-null is the resolved
>>>>>>>> value. With a couple uses of CAS, we can eliminate the need for
>>>>>>>> the constant pool lock for the constant pool changes. Error
>>>>>>>> handling also changes the tag but saving the resolution exception
>>>>>>>> was done under the SystemDictionary_lock, so only the tag change
>>>>>>>> needs a CAS.
>>>>>>>>
>>>>>>>> The only remaining use for the constant pool lock is updating the
>>>>>>>> cpCache for invokedynamic. There are 4 fields that need to be
>>>>>>>> consistent. These now use the metaspace lock associated with the
>>>>>>>> class loader that owns the constant pool, which is only held
>>>>>>>> briefly. I ran some performance tests written by Sergey Kuksenko
>>>>>>>> which show no regression.
>>>>>>>>
>>>>>>>> Other testing - ran refworkload on linux x64 with no significant
>>>>>>>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>>>>>>>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>>>>>>>
>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>>>>>>>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
From karen.kinnear at oracle.com Wed Jun 18 19:09:54 2014
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 18 Jun 2014 15:09:54 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A1DC65.1020304@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com>
<53A1DC65.1020304@oracle.com>
Message-ID: <1F34CCB0-0DE6-4998-84BD-BD773BA6584A@oracle.com>
What happens if folks do a full jdk build during development? Can you send a warning? There
are folks doing that.
thanks,
Karen
On Jun 18, 2014, at 2:37 PM, Coleen Phillimore wrote:
>
> Hi, I missed a question.
>
> On 6/18/14, 2:16 PM, Mandy Chung wrote:
>> Hi Coleen,
>>
>> I'm glad to see this change to go in. Thanks for doing this. The jdk change looks good. Minor comment:
>>
>> 684 // Initialized in JVM not by fake constructor
>> 685 private final ClassLoader classLoader;
>>
>> I prefer to say "Initialized in JVM not by the private constructor"
>> and the comment of the private constructor perhaps can say:
>>
>> /*
>> * Private constructor.Only the Java Virtual Machine creates Class
>> * objects. This constructor is not used and JVM directly injects
>> * value of the instance fields.
>> */
>> private Class(ClassLoader loader) {
>> classLoader = loader;
>> }
>>
>> And It may be worth to mention that the classLoader field is initialized to
>> the given loader parameter instead of null to prepare for possible future JIT optimization.
>>
>> I didn't review the hotspot change. The new classLoader field is not
>> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized
>> jdk/hotspot change? What if you push both changes through the same forest jdk9/hs-rt?
>
> The plan is to push both through hs-rt. The jdk changes don't work without the jvm changes but I think that's fine because both will hit jdk9/dev at the same time. I've prewarned the gatekeepers and Alejandro. The hotspot change works without the jdk change because most people on hotspot don't build full jdks during development (yet).
>
> Thanks,
> Coleen
>>
>> A side note - Christian has a patch attached in this bug that can
>> improve the performance when running with SecurityManager on the
>> classloader related check for permission. Can you create a new
>> bug to track that so that it won't get lost once this bug is
>> resolved?
>>
>> thanks
>> Mandy
>>
>> On 6/16/2014 10:30 PM, David Holmes wrote:
>>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote:
>>>>
>>>>
>>>> /*
>>>> * Constructor. Only the Java Virtual Machine creates Class
>>>> * objects, but this constructor prevents a warning that
>>>> classLoader is not
>>>> * initialized.
>>>> */
>>>> private Class(ClassLoader loader) {
>>>> classLoader = loader;
>>>> }
>>>
>>> Why not just initialize classloader to null when it is declared and leave the constructor alone? The constructor exists to prevent javac from creating a default constructor, and thus ensuring Class instances can not be created (which is what the original comment should, but doesn't quite, say).
>>>
>>> David
>>>
>>>> Coleen
>>>>>
>>>>> Roger
>>>>>
>>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote:
>>>>>> Hi Coleen,
>>>>>> This looks good.
>>>>>> Lois
>>>>>>
>>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote:
>>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access
>>>>>>>
>>>>>>> In order to improve performance of Class.getClassLoader() in a way
>>>>>>> to allow the compilers to automatically optimize this call, I added
>>>>>>> the classLoader to the instance of java/lang/Class. For
>>>>>>> microbenchmarks, this results in a 98% improvement, which was
>>>>>>> expected. For Oracle internal applications, this results in a
>>>>>>> 10-12% improvement on solaris/sparc. The increase in size of
>>>>>>> java/lang/Class can be offset by other changes (removing constant
>>>>>>> pool lock, or removing signers).
>>>>>>>
>>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>>>>>>> associated linked bugs for more details.
>>>>>>>
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>>>>>>
>>>>>>> There is both hotspot and jdk changes for this change. The hotspot
>>>>>>> changes can work without the jdk changes (check for optional field),
>>>>>>> but not vice-versa. I'll file another bug (and compatibility
>>>>>>> request) to remove JVM_GetClassLoader from hotspot.
>>>>>>>
>>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk
>>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
From coleen.phillimore at oracle.com Wed Jun 18 19:17:36 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Jun 2014 15:17:36 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <1F34CCB0-0DE6-4998-84BD-BD773BA6584A@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com>
<53A1DC65.1020304@oracle.com>
<1F34CCB0-0DE6-4998-84BD-BD773BA6584A@oracle.com>
Message-ID: <53A1E5D0.3040203@oracle.com>
On 6/18/14, 3:09 PM, Karen Kinnear wrote:
> What happens if folks do a full jdk build during development? Can you send a warning? There
> are folks doing that.
They will get the right thing because the jdk/jvm changes will always be
in the same repository. It's just the hotspot-only build people this
is accommodating.
Coleen
>
> thanks,
> Karen
>
> On Jun 18, 2014, at 2:37 PM, Coleen Phillimore wrote:
>
>> Hi, I missed a question.
>>
>> On 6/18/14, 2:16 PM, Mandy Chung wrote:
>>> Hi Coleen,
>>>
>>> I'm glad to see this change to go in. Thanks for doing this. The jdk change looks good. Minor comment:
>>>
>>> 684 // Initialized in JVM not by fake constructor
>>> 685 private final ClassLoader classLoader;
>>>
>>> I prefer to say "Initialized in JVM not by the private constructor"
>>> and the comment of the private constructor perhaps can say:
>>>
>>> /*
>>> * Private constructor.Only the Java Virtual Machine creates Class
>>> * objects. This constructor is not used and JVM directly injects
>>> * value of the instance fields.
>>> */
>>> private Class(ClassLoader loader) {
>>> classLoader = loader;
>>> }
>>>
>>> And It may be worth to mention that the classLoader field is initialized to
>>> the given loader parameter instead of null to prepare for possible future JIT optimization.
>>>
>>> I didn't review the hotspot change. The new classLoader field is not
>>> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the synchronized
>>> jdk/hotspot change? What if you push both changes through the same forest jdk9/hs-rt?
>> The plan is to push both through hs-rt. The jdk changes don't work without the jvm changes but I think that's fine because both will hit jdk9/dev at the same time. I've prewarned the gatekeepers and Alejandro. The hotspot change works without the jdk change because most people on hotspot don't build full jdks during development (yet).
>>
>> Thanks,
>> Coleen
>>> A side note - Christian has a patch attached in this bug that can
>>> improve the performance when running with SecurityManager on the
>>> classloader related check for permission. Can you create a new
>>> bug to track that so that it won't get lost once this bug is
>>> resolved?
>>>
>>> thanks
>>> Mandy
>>>
>>> On 6/16/2014 10:30 PM, David Holmes wrote:
>>>> On 17/06/2014 6:43 AM, Coleen Phillimore wrote:
>>>>>
>>>>> /*
>>>>> * Constructor. Only the Java Virtual Machine creates Class
>>>>> * objects, but this constructor prevents a warning that
>>>>> classLoader is not
>>>>> * initialized.
>>>>> */
>>>>> private Class(ClassLoader loader) {
>>>>> classLoader = loader;
>>>>> }
>>>> Why not just initialize classloader to null when it is declared and leave the constructor alone? The constructor exists to prevent javac from creating a default constructor, and thus ensuring Class instances can not be created (which is what the original comment should, but doesn't quite, say).
>>>>
>>>> David
>>>>
>>>>> Coleen
>>>>>> Roger
>>>>>>
>>>>>> On 6/16/2014 1:45 PM, Lois Foltan wrote:
>>>>>>> Hi Coleen,
>>>>>>> This looks good.
>>>>>>> Lois
>>>>>>>
>>>>>>> On 6/16/2014 11:42 AM, Coleen Phillimore wrote:
>>>>>>>> Summary: Add classLoader to java/lang/Class instance for fast access
>>>>>>>>
>>>>>>>> In order to improve performance of Class.getClassLoader() in a way
>>>>>>>> to allow the compilers to automatically optimize this call, I added
>>>>>>>> the classLoader to the instance of java/lang/Class. For
>>>>>>>> microbenchmarks, this results in a 98% improvement, which was
>>>>>>>> expected. For Oracle internal applications, this results in a
>>>>>>>> 10-12% improvement on solaris/sparc. The increase in size of
>>>>>>>> java/lang/Class can be offset by other changes (removing constant
>>>>>>>> pool lock, or removing signers).
>>>>>>>>
>>>>>>>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and
>>>>>>>> associated linked bugs for more details.
>>>>>>>>
>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>>>>>>>
>>>>>>>> There is both hotspot and jdk changes for this change. The hotspot
>>>>>>>> changes can work without the jdk changes (check for optional field),
>>>>>>>> but not vice-versa. I'll file another bug (and compatibility
>>>>>>>> request) to remove JVM_GetClassLoader from hotspot.
>>>>>>>>
>>>>>>>> Tested with jck lang, vm, api/java_lang tests with/without jdk
>>>>>>>> change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>>>>
>>>>>>>>
From mandy.chung at oracle.com Wed Jun 18 19:27:39 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Jun 2014 12:27:39 -0700
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A1DBF5.2090607@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com>
<53A1DBF5.2090607@oracle.com>
Message-ID: <53A1E82B.60109@oracle.com>
On 6/18/2014 11:35 AM, Coleen Phillimore wrote:
>
> /*
> * Private constructor. Only the Java Virtual Machine creates Class
> * objects. This constructor is not used but prevents a warning that
> * classLoader is not initialized. The initialization value of
> non-null
> * prevents future JIT optimizations from assuming this final
> field is null.
> */
>
As David points out, the private constructor is to avoid the default
constructor being generated. Your change to initialize the final
classloader field is a second reason. The second statement reads to me
like the reason for this private constructor is for the warning reason.
Perhaps "but prevents... " gets me confused and maybe that part is not
really needed? Your change looks good anyway.
>>
>> I didn't review the hotspot change. The new classLoader field is not
>> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the
>> synchronized
>> jdk/hotspot change? What if you push both changes through the same
>> forest jdk9/hs-rt?
>
> The new field classLoader is explicit and not injected by the jvm. The
> jvm looks up the offset of the field when it lays out the class Class
> and initializes it directly in the instance of java.lang.Class. So it
> isn't added to the injected fields.
Right... I missed that obvious one.
>>
>> A side note - Christian has a patch attached in this bug that can
>> improve the performance when running with SecurityManager on the
>> classloader related check for permission. Can you create a new
>> bug to track that so that it won't get lost once this bug is
>> resolved?
>
> I didn't completely follow the relationship between Chris's patch and
> this bug. Yes, I'll file a new bug or ask someone who knows more
> about it to do so.
>
Thanks. The patch requires more investigation in the bootstrapping side
of thing.
> The plan is to push both through hs-rt.
Great. That's what I wanted to know.
Mandy
From mikael.vidstedt at oracle.com Wed Jun 18 19:32:54 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 18 Jun 2014 12:32:54 -0700
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <53A14A4A.5090208@oracle.com>
References: <53979E97.1040609@oracle.com>
<5397C2E6.6080603@oracle.com> <5397EEF7.5050006@oracle.com>
<539A1939.80103@oracle.com> <539AA0AC.6090202@oracle.com>
<539F50E1.7090300@oracle.com> <539FACB2.2050508@oracle.com>
<53A092D4.3060100@oracle.com> <53A14A4A.5090208@oracle.com>
Message-ID: <53A1E966.1050808@oracle.com>
Erik/David - thanks for the reviews!
Cheers,
Mikael
On 2014-06-18 01:14, Erik Joelsson wrote:
> Looks ok to me.
>
> /Erik
>
> On 2014-06-17 21:11, Mikael Vidstedt wrote:
>>
>> New webrev here (only the hotspot part, the webrev for top hasn't
>> changed):
>>
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/
>>
>>
>> Comments inline.
>>
>> On 2014-06-16 19:49, David Holmes wrote:
>>> Hi Mikael,
>>>
>>> Sorry for the delay ...
>>>
>>> make/aix/makefiles/defs.make:
>>>
>>> This change doesn't make sense to me:
>>>
>>> 48 ifneq (,$(findstring $(ARCH), ppc))
>>>
>>> given that the logic immediately preceding this sets ARCH to either
>>> ppc or ppc64 based on ARCH_DATA_MODEL. You seem to be trying to
>>> allow for both 32-bit and 64-bit cross-builds but the earlier logic
>>> is really precluding this. So it seems to me that the changes in
>>> this file are completely unnecessary (or else the earlier logic also
>>> needs changing).
>>
>> Indeed, that is correct - I missed the fact that ARCH is always
>> overriden to be either ppc or ppc64. The old logic is unnecessarily
>> hard to follow, but I guess that's in line with our hotspot Makefiles
>> in general ;)
>>
>> I'll revert the changes to the file and add a mental note to self and
>> others that linux appears to be the only platform where the incoming
>> value of ARCH is actually honored - it's ignored/overridden on
>> Solaris, BSD and AIX.
>>
>>> make/linux/makefiles/defs.make
>>>
>>> This block:
>>>
>>> 86 # i686/i586 and amd64/x86_64
>>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
>>> 88 ifeq ($(ARCH_DATA_MODEL), 64)
>>> 89 ARCH_DATA_MODEL = 64
>>> 90 MAKE_ARGS += LP64=1
>>> 91 PLATFORM = linux-amd64
>>> 92 VM_PLATFORM = linux_amd64
>>> 93 HS_ARCH = x86
>>> 94 else
>>> 95 ARCH_DATA_MODEL = 32
>>> 96 PLATFORM = linux-i586
>>> 97 VM_PLATFORM = linux_i486
>>> 98 HS_ARCH = x86
>>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it
>>> 100 ARCH = i686
>>> 101 endif
>>> 102 endif
>>>
>>> seems to allow the user to try and do a 64-bit build on a 32-bit
>>> build machine. Not sure if that would get caught in an earlier
>>> sanity check? (Same is true for the sparc block).
>>
>> While the changes are primarily just intended to cut down on the
>> duplication I don't immediately see the reason why we wouldn't want
>> to allow compiling a 64-bit VM from a 32-bit machine? We're cross
>> compiling all sorts of platforms, so why not allow this if the
>> compiler supports it? I'd prefer to keep it this way.
>>
>>> Also I don't think the following is actually true:
>>>
>>> # We have to reset ARCH to i686 since SRCARCH relies on it
>>> ARCH = i686
>>>
>>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86
>>> architecture designator will simply map to a SRCARCH of x86, as per
>>> defs.make:
>>>
>>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm
>>> ppc zero,$(ARCH)))
>>> ARCH/ = x86
>>> ARCH/sparc = sparc
>>> ARCH/sparc64= sparc
>>> ARCH/ia64 = ia64
>>> ARCH/amd64 = x86
>>> ARCH/x86_64 = x86
>>> ARCH/ppc64 = ppc
>>> ARCH/ppc = ppc
>>> ARCH/arm = arm
>>> ARCH/zero = zero
>>
>> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64,
>> ppc64, ppc, arm, zero } it will map to x86 anyway. I thought about
>> cleaning that up before I sent out the first webrev, but soon found
>> myself doing way more cleanup than was healthy for this specific
>> change. However, since I had to update this change anyway I removed
>> the ARCH reset part.
>>
>> Cheers,
>> Mikael
>>
>>>
>>>
>>> Cheers,
>>> David
>>>
>>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>>>>
>>>> Thanks Erik. Another review please?
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>> On 2014-06-12 23:56, Erik Joelsson wrote:
>>>>> Looks fine to me.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>>>>
>>>>>> I have now verified that the changes work just fine for the
>>>>>> platforms
>>>>>> we build and test - both from the top level and when building
>>>>>> hotspot
>>>>>> only. Taking suggestions on other tests to perform. And it would be
>>>>>> great if somebody could test the changes on on aix/ppc.
>>>>>>
>>>>>> So, kindly asking for "real"/final reviews of the changes:
>>>>>>
>>>>>> top:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>
>>>>>> hotspot:
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> Thanks for the feedback. Essentially the logic in the
>>>>>>> make/<os>/makefiles/defs.make files needs to recognize and deal
>>>>>>> with
>>>>>>> two different use cases:
>>>>>>>
>>>>>>> 1. ARCH being set by the JDK build system to the value of
>>>>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>>>>> typically from uname
>>>>>>>
>>>>>>> Since Solaris and bsd both override ARCH they do not care about
>>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>>>>
>>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes,
>>>>>>> but I
>>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>>>>> the hope that somebody can help out with that.
>>>>>>>
>>>>>>>
>>>>>>> Summing it up, I have the following two webrevs:
>>>>>>>
>>>>>>> top:
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>>
>>>>>>>
>>>>>>> hotspot:
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> With these changes I can build the normal platforms, but more
>>>>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>>>>> feedback is much appreciated!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mikael
>>>>>>>
>>>>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>>>>> Hi Mikael,
>>>>>>>>
>>>>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>>>>
>>>>>>>> As you note the main flow-on effect here is that the hotspot
>>>>>>>> makefiles have to be updated for the cases where
>>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>>>>> only x86 has that issue.
>>>>>>>>
>>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>>>>> both internally and in the build artifacts and bundles!
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> I need some feedback and comments on the below fix:
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Background:
>>>>>>>>>
>>>>>>>>> When configuring the hotspot build the build system sets up
>>>>>>>>> the ARCH
>>>>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>>>>> initialized
>>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>>>>> name. For
>>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on
>>>>>>>>> mac).
>>>>>>>>> The
>>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>>>>> gradually removed in favor of the other variables.
>>>>>>>>>
>>>>>>>>> Discussion:
>>>>>>>>>
>>>>>>>>> The two candidate variables to base ARCH on are as far as I
>>>>>>>>> can tell
>>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a
>>>>>>>>> single, well
>>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }.
>>>>>>>>> Together
>>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough
>>>>>>>>> for the
>>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>>>>> ignored on
>>>>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>>>>
>>>>>>>>> Before I go too far with this though I'd like to get some
>>>>>>>>> feedback on
>>>>>>>>> whether or not this is the right approach and what the exact
>>>>>>>>> value
>>>>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>>>>> system may
>>>>>>>>> have to be updated for some platforms to support the new
>>>>>>>>> value(s).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mikael
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
From coleen.phillimore at oracle.com Wed Jun 18 19:38:43 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Jun 2014 15:38:43 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A1E82B.60109@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com>
<53A1DBF5.2090607@oracle.com> <53A1E82B.60109@oracle.com>
Message-ID: <53A1EAC3.6030102@oracle.com>
On 6/18/14, 3:27 PM, Mandy Chung wrote:
>
> On 6/18/2014 11:35 AM, Coleen Phillimore wrote:
>>
>> /*
>> * Private constructor. Only the Java Virtual Machine creates Class
>> * objects. This constructor is not used but prevents a warning
>> that
>> * classLoader is not initialized. The initialization value of
>> non-null
>> * prevents future JIT optimizations from assuming this final
>> field is null.
>> */
>>
>
> As David points out, the private constructor is to avoid the default
> constructor being generated. Your change to initialize the final
> classloader field is a second reason. The second statement reads to
> me like the reason for this private constructor is for the warning
> reason. Perhaps "but prevents... " gets me confused and maybe that
> part is not really needed? Your change looks good anyway.
How about this? I separated out the two concerns.
/*
* Private constructor. Only the Java Virtual Machine creates Class
objects.
* This constructor is not used and prevents the default
constructor being
* generated.
*/
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The initialization
value of non-null
// prevents future JIT optimizations from assuming this final
field is null.
classLoader = loader;
}
Thanks!
Coleen
>
>>>
>>> I didn't review the hotspot change. The new classLoader field is not
>>> in CLASS_INJECTED_FIELDS - is it just temporary to avoid the
>>> synchronized
>>> jdk/hotspot change? What if you push both changes through the same
>>> forest jdk9/hs-rt?
>>
>> The new field classLoader is explicit and not injected by the jvm.
>> The jvm looks up the offset of the field when it lays out the class
>> Class and initializes it directly in the instance of
>> java.lang.Class. So it isn't added to the injected fields.
>
> Right... I missed that obvious one.
>
>>>
>>> A side note - Christian has a patch attached in this bug that can
>>> improve the performance when running with SecurityManager on the
>>> classloader related check for permission. Can you create a new
>>> bug to track that so that it won't get lost once this bug is
>>> resolved?
>>
>> I didn't completely follow the relationship between Chris's patch and
>> this bug. Yes, I'll file a new bug or ask someone who knows more
>> about it to do so.
>>
>
> Thanks. The patch requires more investigation in the bootstrapping
> side of thing.
>
>> The plan is to push both through hs-rt.
>
> Great. That's what I wanted to know.
>
> Mandy
>
>
From mandy.chung at oracle.com Wed Jun 18 19:42:11 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Jun 2014 12:42:11 -0700
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A1EAC3.6030102@oracle.com>
References: <539F1066.8080302@oracle.com> <539F2D41.7040901@oracle.com> <539F2E75.1050301@oracle.com> <539F56E9.3060705@oracle.com>
<539FD28B.7000201@oracle.com> <53A1D781.7070704@oracle.com>
<53A1DBF5.2090607@oracle.com> <53A1E82B.60109@oracle.com>
<53A1EAC3.6030102@oracle.com>
Message-ID: <53A1EB93.8070004@oracle.com>
On 6/18/2014 12:38 PM, Coleen Phillimore wrote:
>
> On 6/18/14, 3:27 PM, Mandy Chung wrote:
>>
>> On 6/18/2014 11:35 AM, Coleen Phillimore wrote:
>>>
>>> /*
>>> * Private constructor. Only the Java Virtual Machine creates Class
>>> * objects. This constructor is not used but prevents a warning
>>> that
>>> * classLoader is not initialized. The initialization value of
>>> non-null
>>> * prevents future JIT optimizations from assuming this final
>>> field is null.
>>> */
>>>
>>
>> As David points out, the private constructor is to avoid the default
>> constructor being generated. Your change to initialize the final
>> classloader field is a second reason. The second statement reads to
>> me like the reason for this private constructor is for the warning
>> reason. Perhaps "but prevents... " gets me confused and maybe that
>> part is not really needed? Your change looks good anyway.
>
> How about this? I separated out the two concerns.
>
> /*
> * Private constructor. Only the Java Virtual Machine creates
> Class objects.
> * This constructor is not used and prevents the default
> constructor being
> * generated.
> */
> private Class(ClassLoader loader) {
> // Initialize final field for classLoader. The initialization
> value of non-null
> // prevents future JIT optimizations from assuming this final
> field is null.
> classLoader = loader;
> }
>
Looks okay with me.
Mandy
From george.triantafillou at oracle.com Wed Jun 18 22:22:40 2014
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Wed, 18 Jun 2014 18:22:40 -0400
Subject: RFR (M) 8038074: [TESTBUG] Add test for anewarray instruction with
more than 255 dimensions
Message-ID: <53A21130.6090401@oracle.com>
Summary: New ASM test to ensure that anewarray bytecode is valid only if
it specifies 255 or fewer dimensions.
JBS: https://bugs.openjdk.java.net/browse/JDK-8038074
Webrev: http://cr.openjdk.java.net/~gtriantafill/8038074/webrev.00/
<http://cr.openjdk.java.net/%7Egtriantafill/8038074/webrev.00/>
Testing: JTREG to exercise the added test with JDK 8 and JDK 9
Note that the type-inferencing verifier used for <=49.0 ClassFiles
detects an anewarray instruction with exactly 255 dimensions and
incorrectly issues the "Array with too many dimensions" VerifyError.
Thank you,
George
From alejandro.murillo at oracle.com Thu Jun 19 05:39:38 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 18 Jun 2014 23:39:38 -0600
Subject: RFR 8043541: 'fastdebug' is printed twice in java -version
Message-ID: <53A2779A.70201@oracle.com>
Can I get a review for this change?
Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
Note that this was discovered through nightly testing, but is not per se
causing
any failures. It only affects full non product JDK builds. It does not
affect hotspot
only builds.
The bug was initially filed as confidential, it's a p4, if you can't see
the description, here it is:
"After the format of the hotspot version string was changed now
'fastdebug' is showing twice
in the hotspot version output of 'java -version' ONLY on Full non
product JDK builds as shown below:
java version "1.9.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
mixed mode)
-----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^
Background about the fix:
In a nutshell, with this fix, the build target is added to
HOTSPOT_RELEASE_VERSION,
on hotspot/make/defs.make, and on Hotspot ONLY builds, instead of
passing it to
vm_version.cpp through HOTSPOT_TARGET_BUILD.
HOWEVER, given the way the project to build hotspot (only) with Visual
Studio is created,
it is not possible to add that (HOTSPOT_TARGET_BUILD) to
HOTSPOT_RELEASE_VERSION
when the VS project is created, so HOTSPOT_TARGET_BUILD is still passed
to vm_version.cpp,
on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
building
with Visual studio. Building windows with gnu make (as jprt does) will
work as in other platforms.
I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to vm_version.cpp
altogether, but I suspect it
was done that way to append the target build on non product builds when
using Visual studio.
If someone is familiar with the VS create.bat script and visual studio
in general, please
take a look and see if there's a way to pass that info at project
creation time, so that
we can completely get rid of passing HOTSPOT_TARGET_BUILD to
vm_version.cpp.
Please file an RFE if necessary.
With this solution:
(a) For FULL JDK builds, 'fastdebug' will not be duplicated (bug being
fixed) on those builds.
(b) And for JUST hotspot only, non product builds, the output format for
the hotspot
version will slightly change from (see ^^^^^^ below):
java version "1.9.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
Java HotSpot(TM) Server VM (build 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug, mixed mode)
------------------------------------------------------------------------------------------^^^^^^^^^
TO:
java version "1.9.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
Java HotSpot(TM) Server VM (build 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB, mixed mode)
----------------------------------------^^^^^^^^^----------------------------------------------------
Basically 'fastdebug' is now added right after the jdk version, before
'internal',
in the hotspot portion, instead of at the end. Product builds are not
affected at all.
note, those are outputs from hs only JPRT builds. Non JPRT hs only
builds may not have
anything after 'internal' (by default).
thanks
--
Alejandro
From stefan.karlsson at oracle.com Thu Jun 19 08:31:43 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 19 Jun 2014 10:31:43 +0200
Subject: 8047326 : Consolidate all CompiledIC::CompiledIC implementations
and move it to compiledIC.cpp
Message-ID: <53A29FEF.3090406@oracle.com>
Hi all,
Currently, we have exactly the same implementation of
CompiledIC::CompiledIC in all the compiledIC_<arch>.cpp files. I propose
that we get rid of this code duplication and add just one implementation
in the compiledIC.cpp file.
This patch is broken out from the G1 Class Unloading code, so I would
like to push this through the GC repository, if I don't get any objections.
http://cr.openjdk.java.net/~stefank/8047326/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8047326
thanks,
StefanK
From vladimir.x.ivanov at oracle.com Thu Jun 19 09:26:46 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 19 Jun 2014 13:26:46 +0400
Subject: 8047326 : Consolidate all CompiledIC::CompiledIC implementations
and move it to compiledIC.cpp
In-Reply-To: <53A29FEF.3090406@oracle.com>
References: <53A29FEF.3090406@oracle.com>
Message-ID: <53A2ACD6.6020304@oracle.com>
Looks good.
Best regards,
Vladimir Ivanov
On 6/19/14 12:31 PM, Stefan Karlsson wrote:
> Hi all,
>
> Currently, we have exactly the same implementation of
> CompiledIC::CompiledIC in all the compiledIC_<arch>.cpp files. I propose
> that we get rid of this code duplication and add just one implementation
> in the compiledIC.cpp file.
>
> This patch is broken out from the G1 Class Unloading code, so I would
> like to push this through the GC repository, if I don't get any objections.
>
> http://cr.openjdk.java.net/~stefank/8047326/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8047326
>
> thanks,
> StefanK
From stefan.karlsson at oracle.com Thu Jun 19 09:20:16 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 19 Jun 2014 11:20:16 +0200
Subject: 8047326 : Consolidate all CompiledIC::CompiledIC implementations
and move it to compiledIC.cpp
In-Reply-To: <53A2ACD6.6020304@oracle.com>
References: <53A29FEF.3090406@oracle.com> <53A2ACD6.6020304@oracle.com>
Message-ID: <53A2AB50.3010008@oracle.com>
On 2014-06-19 11:26, Vladimir Ivanov wrote:
> Looks good.
Thanks, Vladimir.
StefanK
>
> Best regards,
> Vladimir Ivanov
>
> On 6/19/14 12:31 PM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Currently, we have exactly the same implementation of
>> CompiledIC::CompiledIC in all the compiledIC_<arch>.cpp files. I propose
>> that we get rid of this code duplication and add just one implementation
>> in the compiledIC.cpp file.
>>
>> This patch is broken out from the G1 Class Unloading code, so I would
>> like to push this through the GC repository, if I don't get any
>> objections.
>>
>> http://cr.openjdk.java.net/~stefank/8047326/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8047326
>>
>> thanks,
>> StefanK
From erik.helin at oracle.com Thu Jun 19 10:15:26 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 19 Jun 2014 12:15:26 +0200
Subject: 8047326 : Consolidate all CompiledIC::CompiledIC implementations
and move it to compiledIC.cpp
In-Reply-To: <53A29FEF.3090406@oracle.com>
References: <53A29FEF.3090406@oracle.com>
Message-ID: <11598835.KtIkeojsE8@ehelin-laptop>
Hi Stefan,
thanks for splitting the G1 class unloading patch into smaller pieces!
On Thursday 19 June 2014 10:31:43 AM Stefan Karlsson wrote:
> Hi all,
>
> Currently, we have exactly the same implementation of
> CompiledIC::CompiledIC in all the compiledIC_<arch>.cpp files. I propose
> that we get rid of this code duplication and add just one implementation
> in the compiledIC.cpp file.
>
> This patch is broken out from the G1 Class Unloading code, so I would
> like to push this through the GC repository, if I don't get any objections.
>
> http://cr.openjdk.java.net/~stefank/8047326/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8047326
Looks good, Reviewed.
Thanks,
Erik
> thanks,
> StefanK
From stefan.karlsson at oracle.com Thu Jun 19 10:49:34 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 19 Jun 2014 12:49:34 +0200
Subject: 8047326 : Consolidate all CompiledIC::CompiledIC implementations
and move it to compiledIC.cpp
In-Reply-To: <11598835.KtIkeojsE8@ehelin-laptop>
References: <53A29FEF.3090406@oracle.com> <11598835.KtIkeojsE8@ehelin-laptop>
Message-ID: <53A2C03E.10806@oracle.com>
On 2014-06-19 12:15, Erik Helin wrote:
> Hi Stefan,
>
> thanks for splitting the G1 class unloading patch into smaller pieces!
>
> On Thursday 19 June 2014 10:31:43 AM Stefan Karlsson wrote:
>> Hi all,
>>
>> Currently, we have exactly the same implementation of
>> CompiledIC::CompiledIC in all the compiledIC_<arch>.cpp files. I propose
>> that we get rid of this code duplication and add just one implementation
>> in the compiledIC.cpp file.
>>
>> This patch is broken out from the G1 Class Unloading code, so I would
>> like to push this through the GC repository, if I don't get any objections.
>>
>> http://cr.openjdk.java.net/~stefank/8047326/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8047326
> Looks good, Reviewed.
Thanks.
StefanK
>
> Thanks,
> Erik
>
>> thanks,
>> StefanK
From erik.helin at oracle.com Thu Jun 19 11:05:13 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 19 Jun 2014 13:05:13 +0200
Subject: RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected
heap size on sparcv9
In-Reply-To: <53A1BD6E.2030708@oracle.com>
References: <5368A0D6.5050609@oracle.com> <536BA420.5000408@oracle.com>
<53A1BD6E.2030708@oracle.com>
Message-ID: <2455469.Y4YiF8il66@ehelin-laptop>
On Wednesday 18 June 2014 09:25:18 AM Jon Masamitsu wrote:
> On 05/08/2014 08:34 AM, Erik Helin wrote:
> > Hi Stefan,
> >
> > thanks for your thorough review! Please see new webrev at:
> > http://cr.openjdk.java.net/~ehelin/8027915/webrev.01/
> >
> > and incremental webrev at:
> > http://cr.openjdk.java.net/~ehelin/8027915/webrev.00-01/
>
> Looks good.
Thanks!
Erik
> Reviewed.
>
> Jon
>
> > and comments inline!
> >
> > On 2014-05-06 13:12, Stefan Johansson wrote:
> >> Hi Erik,
> >>
> >> Thanks for making page_size_for_region more strict. A few comments:
> >>
> >> src/share/vm/runtime/os.cpp
> >>
> >> With this fix page_size_for_region doesn't care about alignment at all
> >> (old version wasn't much better) and to me that feels wrong. I would
> >> expect to get a page size that the given region sizes is aligned to, but
> >> I might be missing some use case where that isn't needed.
> >
> > Agree, page_size_for_region should check alignment for large pages.
> > Added fix and regression tests.
> >
> > On 2014-05-06 13:12, Stefan Johansson wrote:
> >> src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
> >>
> >> For the heap we want both min and max to be a multiple of the page size
> >> so we shoud call page_size_for_region for both _min_heap_byte_size and
> >> _max_heap_byte_size and use the smallest of the two returned page sizes.
> >
> > Agree, fixed.
> >
> > On 2014-05-06 13:12, Stefan Johansson wrote:
> >> src/share/vm/memory/heap.cpp
> >>
> >> The current patch will not change the default behavior so I'm fine with
> >> just calling page_size_for_region once using reserved_size, but someone
> >> with more insight might know if we should handle it the same way as the
> >> generationSizer and use both committed and reserved.
> >
> > Since I'm not sure how the compiler guys want to handle this, I opted
> > for the safe alternative and updated the patch to be backwards
> > compatible with the old code (except slightly more strict).
> >
> > Thanks,
> > Erik
> >
> >> Thanks,
> >> Stefan
> >>
> >> On 2014-05-06 10:44, Erik Helin wrote:
> >>> Hi all,
> >>>
> >>> this patch changes
> >>> os::page_size_for_region(min_size, max_size, min_pages) to always
> >>> guarantee that the returned page size <= max_size / min_pages. Prior
> >>> to this patch, page_size_for_region could return a page size larger
> >>> than max_size / min_pages. This can cause some unexpected behavior
> >>> for code using page_size_for_region, such as the following regression
> >>> tests:
> >>>
> >>> http://cr.openjdk.java.net/~ehelin/8027915/regression-test/
> >>>
> >>> As the test shows, if you have a 2 MB region and you must use at least
> >>> 2 pages, you would still get back 2 MB as the page size on a Linux
> >>> machine that supports 2 MB large pages. The reason for this is
> >>> explained in a comment above the function in os.hpp:
> >>>
> >>> // The current implementation ignores min_pages if a larger page
> >>> // size is an exact multiple of both region_min_size and
> >>> // region_max_size. This allows larger pages to be used when doing
> >>> // so would not cause fragmentation; in particular, a single page can
> >>> // be used when region_min_size == region_max_size == a supported page
> >>> // size.
> >>>
> >>> Reducing fragmentation of large pages is good but the varying return
> >>> value makes it very hard to depend on os::page_size_for_region in
> >>> calculations (for example when sizing the heap).
> >>>
> >>> This patch removes the fragmentation prevention mechanism, simplifies
> >>> the function and adds a regression tests:
> >>>
> >>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00/
> >>>
> >>> Testing:
> >>> - JPRT
> >>>
> >>> Thanks,
> >>> Erik
From erik.helin at oracle.com Thu Jun 19 11:05:35 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 19 Jun 2014 13:05:35 +0200
Subject: RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected
heap size on sparcv9
In-Reply-To: <53A033E2.8010806@oracle.com>
References: <5368A0D6.5050609@oracle.com> <1435735.yAz5aBB6y5@ehelin-laptop>
<53A033E2.8010806@oracle.com>
Message-ID: <50115791.bmHjG2qMIz@ehelin-laptop>
On Tuesday 17 June 2014 14:26:10 PM Stefan Johansson wrote:
> On 2014-06-17 13:15, Erik Helin wrote:
> > Hi Stefan,
> >
> > sorry for the late reply, please see my comments inline.
> >
> > On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
> >> On 2014-05-08 17:34, Erik Helin wrote:
> >>> Hi Stefan,
> >>>
> >>> thanks for your thorough review! Please see new webrev at:
> >>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.01/
> >>>
> >>> and incremental webrev at:
> >>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00-01/
> >>>
> >>> and comments inline!
> >>>
> >>> On 2014-05-06 13:12, Stefan Johansson wrote:
> >>>> Hi Erik,
> >>>>
> >>>> Thanks for making page_size_for_region more strict. A few comments:
> >>>>
> >>>> src/share/vm/runtime/os.cpp
> >>>>
> >>>> With this fix page_size_for_region doesn't care about alignment at all
> >>>> (old version wasn't much better) and to me that feels wrong. I would
> >>>> expect to get a page size that the given region sizes is aligned to,
> >>>> but
> >>>> I might be missing some use case where that isn't needed.
> >>>
> >>> Agree, page_size_for_region should check alignment for large pages.
> >>> Added fix and regression tests.
> >>
> >> Good fix.
> >
> > Thanks!
> >
> > On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
> >> Regarding the testing, I looked at the code and the _page_sizes array is
> >> public. You could start of the testing with recording all "real" values
> >> and then set up an array that allows more testing. It would be nice to
> >> have a case in the alignment test that makes sure for example that for a
> >> 10M region you can get 2M pages but not 4M pages. If doing this you need
> >> to make sure the values in the _page_sizes array are set back to normal
> >> after the test. This would also allow the test to run even if
> >> UseLargePages isn't set.
> >
> > I agree that this is a good idea, but I'm not fond of modifying the
> > _page_sizes array. Even though the VM is quite idle when the internal
> > vm tests are running, there is a possibility that threads running
> > concurrently might pick up a strange value from the _page_sizes
> > array. Diagnosing an eventual crash due to this might be tricky :)
> >
> > What do you think of this?
>
> I agree, and as we discussed off-line, this kind of tests would be
> easier to write if we had a better unit-testing framework. With that in
> mind I'm ok with leaving the test as is for now.
Thanks,
Erik
> Thanks,
> Stefan
>
> > On Tuesday 13 May 2014 14:31:10 PM Stefan Johansson wrote:
> >>> On 2014-05-06 13:12, Stefan Johansson wrote:
> >>>> src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
> >>>>
> >>>> For the heap we want both min and max to be a multiple of the page size
> >>>> so we shoud call page_size_for_region for both _min_heap_byte_size and
> >>>> _max_heap_byte_size and use the smallest of the two returned page
> >>>> sizes.
> >>>
> >>> Agree, fixed.
> >>
> >> Great!
> >
> > Thanks,
> > Erik
> >
> >>> On 2014-05-06 13:12, Stefan Johansson wrote:
> >>>> src/share/vm/memory/heap.cpp
> >>>>
> >>>> The current patch will not change the default behavior so I'm fine with
> >>>> just calling page_size_for_region once using reserved_size, but someone
> >>>> with more insight might know if we should handle it the same way as the
> >>>> generationSizer and use both committed and reserved.
> >>>
> >>> Since I'm not sure how the compiler guys want to handle this, I opted
> >>> for the safe alternative and updated the patch to be backwards
> >>> compatible with the old code (except slightly more strict).
> >>
> >> I agree that this is probably the correct solution, but it would be nice
> >> to hear what the compiler guys think. As you say, this is a little more
> >> strict and there might be cases where we now stop getting large pages
> >> where we used to before.
> >>
> >> To summarize, I think the changes are good but wouldn't mind some
> >> improved tests for it.
> >>
> >> Stefan
> >>
> >>> Thanks,
> >>> Erik
> >>>
> >>>> Thanks,
> >>>> Stefan
> >>>>
> >>>> On 2014-05-06 10:44, Erik Helin wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> this patch changes
> >>>>> os::page_size_for_region(min_size, max_size, min_pages) to always
> >>>>> guarantee that the returned page size <= max_size / min_pages. Prior
> >>>>> to this patch, page_size_for_region could return a page size larger
> >>>>> than max_size / min_pages. This can cause some unexpected behavior
> >>>>> for code using page_size_for_region, such as the following regression
> >>>>> tests:
> >>>>>
> >>>>> http://cr.openjdk.java.net/~ehelin/8027915/regression-test/
> >>>>>
> >>>>> As the test shows, if you have a 2 MB region and you must use at least
> >>>>> 2 pages, you would still get back 2 MB as the page size on a Linux
> >>>>> machine that supports 2 MB large pages. The reason for this is
> >>>>> explained in a comment above the function in os.hpp:
> >>>>>
> >>>>> // The current implementation ignores min_pages if a larger page
> >>>>> // size is an exact multiple of both region_min_size and
> >>>>> // region_max_size. This allows larger pages to be used when doing
> >>>>> // so would not cause fragmentation; in particular, a single page can
> >>>>> // be used when region_min_size == region_max_size == a supported page
> >>>>> // size.
> >>>>>
> >>>>> Reducing fragmentation of large pages is good but the varying return
> >>>>> value makes it very hard to depend on os::page_size_for_region in
> >>>>> calculations (for example when sizing the heap).
> >>>>>
> >>>>> This patch removes the fragmentation prevention mechanism, simplifies
> >>>>> the function and adds a regression tests:
> >>>>>
> >>>>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00/
> >>>>>
> >>>>> Testing:
> >>>>> - JPRT
> >>>>>
> >>>>> Thanks,
> >>>>> Erik
From bengt.rutisson at oracle.com Thu Jun 19 11:36:39 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 19 Jun 2014 13:36:39 +0200
Subject: RFR (M): JDK-8043607: Add a GC id as a log decoration similar
to PrintGCTimeStamps
In-Reply-To: <53996ABD.5000003@oracle.com>
References: <537C7264.70200@oracle.com> <537DAA00.2010104@oracle.com> <537ED5FC.6080702@oracle.com> <2198629.dbW8eWbo0l@ehelin-desktop> <538F35DE.1040802@oracle.com> <1401978537.2592.5.camel@cirrus> <5390D9F9.2080202@oracle.com>
<5395A2DA.3000507@oracle.com> <1402391343.2588.15.camel@cirrus>
<5396FC14.5010705@oracle.com> <1402424676.2701.7.camel@cirrus>
<53996ABD.5000003@oracle.com>
Message-ID: <53A2CB47.7050302@oracle.com>
Hi again,
Been discussing this patch offline with Erik. He had suggested some
changes but is now fine with the change. I will push this now.
Here's the final webrev:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.08/
Here's the diff compared to the last one:
http://cr.openjdk.java.net/~brutisso/8043607/webrev.07-08.diff/
Thanks Jesper, Erik and Thomas for reviewing it!
Bengt
On 2014-06-12 10:54, Bengt Rutisson wrote:
>
> Hi again,
>
> Erik noticed two things. I had done an unnecessary change in
> g1CollectedHeap.cpp and there were issues with getting the correct GC
> ID for logging an aborted concurrent cycle in G1.
>
> I've reverted the unnecessary change in g1CollectedHeap.cpp and I
> suggest to solve the issue with the aborted concurrent cycle by
> keeping track of the GC id that we abort and use that for logging.
>
> Here's an updated webrev:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.07/
>
> Here's the diff copared to the last one:
> http://cr.openjdk.java.net/~brutisso/8043607/webrev.06-07.diff/
>
> Thanks,
> Bengt
>
>
>
> On 2014-06-10 20:24, Thomas Schatzl wrote:
>> Hi,
>>
>> On Tue, 2014-06-10 at 14:37 +0200, Bengt Rutisson wrote:
>>> Hi Thomas,
>>>
>>> Thanks for looking at this again!
>>>> Regarding the test and possible backporting: the test currently
>>>> assumes
>>>> that gc id printing is on by default. Wouldn't it be better to specify
>>>> +/-PrintGCId in the these tests to make sure it also works with
>>>> different default settings, and possibly one run checking default
>>>> settings?
>>> Good point. I updated the test:
>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/test/gc/logging/TestGCId.java.html
>>>
>>>
>>> Full new webrev (only the test has changed):
>>> http://cr.openjdk.java.net/~brutisso/8043607/webrev.06/
>>>
>>>> You mentioned somewhere that you want to backport this change to 8u
>>>> with
>>>> the default value of PrintGCid to be false (iirc) too.
>>> Right. That is my plan. I will need to send out a separate review for
>>> that since I will do a code change (the default value in globals.hpp),
>>> so we can discuss the details during that review. With the new test the
>>> only required change is to switch verify method for the default case.
>> Okay. Looks good to me.
>>
>> Thomas
>>
>
From bengt.rutisson at oracle.com Thu Jun 19 12:55:52 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 19 Jun 2014 14:55:52 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <53A18A50.50001@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz> <5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com> <20140613095511.5fae7c4b483bb65f073e5628@danny.cz> <539AEA4D.8020204@oracle.com> <20140613145531.559f6d943ef097550580a1f6@danny.cz> <539E8F41.6070001@oracle.com> <20140616091702.28b895ce918bdf4c58d2506f@danny.cz> <539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com> <20140616162130.ac9bec274c625241bb7fd18d@danny.cz> <539F0CA0.3010309@oracle.com> <20140616182920.baccf0cc83debbe522189688@danny.cz> <539F22E0.2080202@oracle.com> <20140618085537.0cc3e3e85856ae67c491c88e@danny.cz>
<53A18A50.50001@oracle.com>
Message-ID: <53A2DDD8.4010605@oracle.com>
Jesper,
Thanks for uploading the webrev on the openjdk server.
Dan,
Can you explain more in detail why it is not possible to specialize the
MIN2 and MAX2 functions? You are probably correct, because when I read
the comment in the code it says:
// It is necessary to use templates here. Having normal overloaded
// functions does not work because it is necessary to provide both 32-
// and 64-bit overloaded functions, which does not work, and having
// explicitly-typed versions of these routines (i.e., MAX2I, MAX2L)
// will be even more error-prone than macros.
template<class T> inline T MAX2(T a, T b) { return (a > b) ? a
: b; }
This kind of says what you also said. That it is not possible, but it
does not really explain why.
Can you explain why we can have definitions like:
inline uint MAX2(uint a, size_t b)
inline uint MAX2(size_t a, uint b)
to complement the present template version?
Thanks,
Bengt
On 6/18/14 2:47 PM, Jesper Wilhelmsson wrote:
> Hi Dan,
>
> I have uploaded your webrev here:
>
> http://cr.openjdk.java.net/~jwilhelm/8046938/webrev/
>
> The change looks good to me.
> /Jesper
>
>
> Dan Hor?k skrev 18/6/14 08:55:
>> On Mon, 16 Jun 2014 19:01:20 +0200
>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>
>>> Hi Dan,
>>>
>>> I created a bug four this issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8046938
>>> /Jesper
>>
>> updated webrev is now at http://fedora.danny.cz/openjdk/size_t-2/webrev/
>> (and http://fedora.danny.cz/openjdk/size_t-2/webrev.zip)
>>
>> changes:
>> - refreshed for current hs-gc repository
>> - dropped unnecessary typecast in get_hum_bytes() (concurrentMark.cpp)
>> - typecasts in FLAG_SET_ERGO() changed to uintx from size_t
>> (arguments.cpp)
>>
>>
>> With regards
>>
>> Dan
>>
>>> Dan Hor?k skrev 16/6/14 18:29:
>>>> On Mon, 16 Jun 2014 17:26:24 +0200
>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>
>>>>> Hi Dan,
>>>>>
>>>>> Since you got a comment from Bengt maybe you should fix that issue
>>>>> before I upload the new webrev.
>>>>>
>>>>> I looked through the webrev and I have one additional comment. I
>>>>> would prefer if the changes in arguments.cpp was the other way,
>>>>> casting stuff to uintx instead of size_t, since we use the result
>>>>> of MAX and MIN to set flags of type uintx.
>>>>
>>>> I wasn't sure what would be better approach here
>>>>
>>>>> When I applied the webrev a change in
>>>>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp got in the
>>>>> way of the patch. The patch still applies but with an offset, so
>>>>> patch complains. If you build a new webrev with the changes above,
>>>>> also pull down the latest hs-gc to get the g1CollectedHeap.cpp
>>>>> change.
>>>>
>>>> thanks for the comments, I'll prepare new webrev hopefully tomorrow
>>>>
>>>>
>>>> Dan
>>>>
>>>>> Thanks!
>>>>> /Jesper
>>>>>
>>>>>
>>>>> Dan Hor?k skrev 16/6/14 16:21:
>>>>>> On Mon, 16 Jun 2014 16:19:17 +0200
>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>>
>>>>>>> Dan,
>>>>>>>
>>>>>>> I can host the webrev. Send me the zipped webrev archive and I'll
>>>>>>> upload it to cr.openjdk.
>>>>>>
>>>>>> Jesper, thanks a lot, the whole archive is at
>>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
>>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>> /Jesper
>>>>>>>
>>>>>>> David Holmes skrev 16/6/14 13:15:
>>>>>>>> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
>>>>>>>>> On Mon, 16 Jun 2014 16:31:29 +1000
>>>>>>>>> David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
>>>>>>>>>>> On Fri, 13 Jun 2014 14:10:53 +0200
>>>>>>>>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>>>>>>>>>>> Then a formality comment. I think you have to post the
>>>>>>>>>>>> webrev on cr.openjdk.java.net to get the legal stuff
>>>>>>>>>>>> correct.
>>>>>>>>>>>
>>>>>>>>>>> hm, I've used this procedure (my webrev, then someone
>>>>>>>>>>> privileged takes it and pushes it) few times in the past and
>>>>>>>>>>> it worked.
>>>>>>>>>>
>>>>>>>>>> We've been advised that all contributions have to come in via
>>>>>>>>>> OpenJDK infrastructure - either a webrev on
>>>>>>>>>> cr.openjdk.java.net or as attachments to mailing list mails.
>>>>>>>>>
>>>>>>>>> I understand, but AFAIK cr.openjdk.java.net is accessible only
>>>>>>>>> to people with push access, which I'm not.
>>>>>>>>
>>>>>>>> No you only need Author status, not Committer.
>>>>>>>>
>>>>>>>>> So the question is will the list
>>>>>>>>> accept 3MB attachment? It is the size of the zipped webrev. Or
>>>>>>>>> will a plain text patch suffice?
>>>>>>>>
>>>>>>>> For large webrevs you may be able to find someone to host it for
>>>>>>>> you on cr.openjdk. I don't know what limit exists on the mailing
>>>>>>>> list but I'd hate to see very large patches submitted that way.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Bengt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
>>>>>>>>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
>>>>>>>>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which repository is the patch built on? Since it is mostly
>>>>>>>>>>>>>> GC code it would be good if it goes in through jdk9/hs-gc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The changes looks good in the webrev, but the patch did
>>>>>>>>>>>>>> not apply to a recent jdk9/hs-gc. Especially the collector
>>>>>>>>>>>>>> policy code has changed a lot recently.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would prefer to look at the changes applied in my
>>>>>>>>>>>>>> workspace before approving it, so if you could update to a
>>>>>>>>>>>>>> recent hs-gc it would be great.
>>>>>>>>>>>>> I have refreshed the patch for the hs-gc repository, please
>>>>>>>>>>>>> see http://fedora.danny.cz/openjdk/size_t-1/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>> /Jesper
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
>>>>>>>>>>>>>>> Thank you, Dan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think casting is acceptable solution. Someone in GC
>>>>>>>>>>>>>>> group should review and sponsor this since you touched
>>>>>>>>>>>>>>> GC code mostly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> this the last and largest part of my changes required on
>>>>>>>>>>>>>>>> s390 (32-bit) to build OpenJDK out of the box. The
>>>>>>>>>>>>>>>> MIN2/MAX2 functions are implemented using templates and
>>>>>>>>>>>>>>>> require both arguments to be of the same type. This is a
>>>>>>>>>>>>>>>> problem when one parameter is of size_t type and the
>>>>>>>>>>>>>>>> second of uintx type and the platform has size_t defined
>>>>>>>>>>>>>>>> as eg. unsigned long as on s390 (32-bit).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As a solution [1] I chose to typecast the smaller type
>>>>>>>>>>>>>>>> (uintx) to size_t which is of same or larger size.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I
>>>>>>>>>>>>>>>> should be covered by Red Hat's CLA for my contributions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> With regards
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
From dan at danny.cz Thu Jun 19 13:06:54 2014
From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=)
Date: Thu, 19 Jun 2014 15:06:54 +0200
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <53A2DDD8.4010605@oracle.com>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
<539AEA4D.8020204@oracle.com>
<20140613145531.559f6d943ef097550580a1f6@danny.cz>
<539E8F41.6070001@oracle.com>
<20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
<539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com>
<20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
<539F0CA0.3010309@oracle.com>
<20140616182920.baccf0cc83debbe522189688@danny.cz>
<539F22E0.2080202@oracle.com>
<20140618085537.0cc3e3e85856ae67c491c88e@danny.cz>
<53A18A50.50001@oracle.com> <53A2DDD8.4010605@oracle.com>
Message-ID: <20140619150654.cf6c68f626234f01295fec61@danny.cz>
On Thu, 19 Jun 2014 14:55:52 +0200
Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>
> Jesper,
>
> Thanks for uploading the webrev on the openjdk server.
>
> Dan,
>
> Can you explain more in detail why it is not possible to specialize
> the MIN2 and MAX2 functions? You are probably correct, because when I
> read the comment in the code it says:
>
>
> // It is necessary to use templates here. Having normal overloaded
> // functions does not work because it is necessary to provide both 32-
> // and 64-bit overloaded functions, which does not work, and having
> // explicitly-typed versions of these routines (i.e., MAX2I, MAX2L)
> // will be even more error-prone than macros.
> template<class T> inline T MAX2(T a, T b) { return (a >
> b) ? a : b; }
>
>
> This kind of says what you also said. That it is not possible, but it
> does not really explain why.
>
> Can you explain why we can have definitions like:
>
> inline uint MAX2(uint a, size_t b)
> inline uint MAX2(size_t a, uint b)
if I remember correctly from my previous experience, these 2 definition
conflict with the existing
inline uint MAX2(uint a, uint b)
on platforms where size_t == uint. But I might be wrong, the easiest we
can do, is to try add them. Or we could add the new definitions only
for s390 with #if defined(__s390__) && ! defined(__s390x__). Or maybe
there is another way to add them only when size_t != uint. A C++ expert
is required :-)
Dan
> to complement the present template version?
>
> Thanks,
> Bengt
>
> On 6/18/14 2:47 PM, Jesper Wilhelmsson wrote:
> > Hi Dan,
> >
> > I have uploaded your webrev here:
> >
> > http://cr.openjdk.java.net/~jwilhelm/8046938/webrev/
> >
> > The change looks good to me.
> > /Jesper
> >
> >
> > Dan Hor?k skrev 18/6/14 08:55:
> >> On Mon, 16 Jun 2014 19:01:20 +0200
> >> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>
> >>> Hi Dan,
> >>>
> >>> I created a bug four this issue:
> >>> https://bugs.openjdk.java.net/browse/JDK-8046938
> >>> /Jesper
> >>
> >> updated webrev is now at
> >> http://fedora.danny.cz/openjdk/size_t-2/webrev/ (and
> >> http://fedora.danny.cz/openjdk/size_t-2/webrev.zip)
> >>
> >> changes:
> >> - refreshed for current hs-gc repository
> >> - dropped unnecessary typecast in get_hum_bytes()
> >> (concurrentMark.cpp)
> >> - typecasts in FLAG_SET_ERGO() changed to uintx from size_t
> >> (arguments.cpp)
> >>
> >>
> >> With regards
> >>
> >> Dan
> >>
> >>> Dan Hor?k skrev 16/6/14 18:29:
> >>>> On Mon, 16 Jun 2014 17:26:24 +0200
> >>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>>>
> >>>>> Hi Dan,
> >>>>>
> >>>>> Since you got a comment from Bengt maybe you should fix that
> >>>>> issue before I upload the new webrev.
> >>>>>
> >>>>> I looked through the webrev and I have one additional comment. I
> >>>>> would prefer if the changes in arguments.cpp was the other way,
> >>>>> casting stuff to uintx instead of size_t, since we use the
> >>>>> result of MAX and MIN to set flags of type uintx.
> >>>>
> >>>> I wasn't sure what would be better approach here
> >>>>
> >>>>> When I applied the webrev a change in
> >>>>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp got in the
> >>>>> way of the patch. The patch still applies but with an offset, so
> >>>>> patch complains. If you build a new webrev with the changes
> >>>>> above, also pull down the latest hs-gc to get the
> >>>>> g1CollectedHeap.cpp change.
> >>>>
> >>>> thanks for the comments, I'll prepare new webrev hopefully
> >>>> tomorrow
> >>>>
> >>>>
> >>>> Dan
> >>>>
> >>>>> Thanks!
> >>>>> /Jesper
> >>>>>
> >>>>>
> >>>>> Dan Hor?k skrev 16/6/14 16:21:
> >>>>>> On Mon, 16 Jun 2014 16:19:17 +0200
> >>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
> >>>>>>
> >>>>>>> Dan,
> >>>>>>>
> >>>>>>> I can host the webrev. Send me the zipped webrev archive and
> >>>>>>> I'll upload it to cr.openjdk.
> >>>>>>
> >>>>>> Jesper, thanks a lot, the whole archive is at
> >>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev.zip
> >>>>>>
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>> /Jesper
> >>>>>>>
> >>>>>>> David Holmes skrev 16/6/14 13:15:
> >>>>>>>> On 16/06/2014 5:17 PM, Dan Hor?k wrote:
> >>>>>>>>> On Mon, 16 Jun 2014 16:31:29 +1000
> >>>>>>>>> David Holmes <david.holmes at oracle.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 13/06/2014 10:55 PM, Dan Hor?k wrote:
> >>>>>>>>>>> On Fri, 13 Jun 2014 14:10:53 +0200
> >>>>>>>>>>> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> >>>>>>>>>>>> Then a formality comment. I think you have to post the
> >>>>>>>>>>>> webrev on cr.openjdk.java.net to get the legal stuff
> >>>>>>>>>>>> correct.
> >>>>>>>>>>>
> >>>>>>>>>>> hm, I've used this procedure (my webrev, then someone
> >>>>>>>>>>> privileged takes it and pushes it) few times in the past
> >>>>>>>>>>> and it worked.
> >>>>>>>>>>
> >>>>>>>>>> We've been advised that all contributions have to come in
> >>>>>>>>>> via OpenJDK infrastructure - either a webrev on
> >>>>>>>>>> cr.openjdk.java.net or as attachments to mailing list
> >>>>>>>>>> mails.
> >>>>>>>>>
> >>>>>>>>> I understand, but AFAIK cr.openjdk.java.net is accessible
> >>>>>>>>> only to people with push access, which I'm not.
> >>>>>>>>
> >>>>>>>> No you only need Author status, not Committer.
> >>>>>>>>
> >>>>>>>>> So the question is will the list
> >>>>>>>>> accept 3MB attachment? It is the size of the zipped webrev.
> >>>>>>>>> Or will a plain text patch suffice?
> >>>>>>>>
> >>>>>>>> For large webrevs you may be able to find someone to host it
> >>>>>>>> for you on cr.openjdk. I don't know what limit exists on the
> >>>>>>>> mailing list but I'd hate to see very large patches
> >>>>>>>> submitted that way.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> David
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Dan
> >>>>>>>>>
> >>>>>>>>>> David
> >>>>>>>>>> -----
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Dan
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Bengt
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 2014-06-13 09:55, Dan Hor?k wrote:
> >>>>>>>>>>>>> On Thu, 12 Jun 2014 21:49:40 +0200
> >>>>>>>>>>>>> Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Which repository is the patch built on? Since it is
> >>>>>>>>>>>>>> mostly GC code it would be good if it goes in through
> >>>>>>>>>>>>>> jdk9/hs-gc.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The changes looks good in the webrev, but the patch did
> >>>>>>>>>>>>>> not apply to a recent jdk9/hs-gc. Especially the
> >>>>>>>>>>>>>> collector policy code has changed a lot recently.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I would prefer to look at the changes applied in my
> >>>>>>>>>>>>>> workspace before approving it, so if you could update
> >>>>>>>>>>>>>> to a recent hs-gc it would be great.
> >>>>>>>>>>>>> I have refreshed the patch for the hs-gc repository,
> >>>>>>>>>>>>> please see
> >>>>>>>>>>>>> http://fedora.danny.cz/openjdk/size_t-1/webrev/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>> /Jesper
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Vladimir Kozlov skrev 12/6/14 20:57:
> >>>>>>>>>>>>>>> Thank you, Dan
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think casting is acceptable solution. Someone in GC
> >>>>>>>>>>>>>>> group should review and sponsor this since you touched
> >>>>>>>>>>>>>>> GC code mostly.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>> Vladimir
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 6/12/14 2:05 AM, Dan Hor?k wrote:
> >>>>>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> this the last and largest part of my changes
> >>>>>>>>>>>>>>>> required on s390 (32-bit) to build OpenJDK out of
> >>>>>>>>>>>>>>>> the box. The MIN2/MAX2 functions are implemented
> >>>>>>>>>>>>>>>> using templates and require both arguments to be of
> >>>>>>>>>>>>>>>> the same type. This is a problem when one parameter
> >>>>>>>>>>>>>>>> is of size_t type and the second of uintx type and
> >>>>>>>>>>>>>>>> the platform has size_t defined as eg. unsigned long
> >>>>>>>>>>>>>>>> as on s390 (32-bit).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> As a solution [1] I chose to typecast the smaller
> >>>>>>>>>>>>>>>> type (uintx) to size_t which is of same or larger
> >>>>>>>>>>>>>>>> size.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [1] http://fedora.danny.cz/openjdk/size_t/webrev/
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Note: I'm Red Hat employee (dhorak at redhat.com), so I
> >>>>>>>>>>>>>>>> should be covered by Red Hat's CLA for my
> >>>>>>>>>>>>>>>> contributions.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> With regards
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>
>
From lois.foltan at oracle.com Thu Jun 19 13:26:59 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 19 Jun 2014 09:26:59 -0400
Subject: RFR (M) 8038074: [TESTBUG] Add test for anewarray instruction
with more than 255 dimensions
In-Reply-To: <53A21130.6090401@oracle.com>
References: <53A21130.6090401@oracle.com>
Message-ID: <53A2E523.5070401@oracle.com>
Thanks George for writing this test case. Looks good!
Lois
On 6/18/2014 6:22 PM, George Triantafillou wrote:
> Summary: New ASM test to ensure that anewarray bytecode is valid only
> if it specifies 255 or fewer dimensions.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8038074
> Webrev:
> http://cr.openjdk.java.net/~gtriantafill/8038074/webrev.00/
> <http://cr.openjdk.java.net/%7Egtriantafill/8038074/webrev.00/>
> Testing: JTREG to exercise the added test with JDK 8 and JDK 9
>
> Note that the type-inferencing verifier used for <=49.0 ClassFiles
> detects an anewarray instruction with exactly 255 dimensions and
> incorrectly issues the "Array with too many dimensions" VerifyError.
>
> Thank you,
>
> George
From aph at redhat.com Thu Jun 19 14:27:32 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Jun 2014 15:27:32 +0100
Subject: RFD: Draft JEP for AArch64
Message-ID: <53A2F354.40606@redhat.com>
The JEP is here:
https://bugs.openjdk.java.net/browse/JDK-8044552
As you may know, we've been working on this port for some time.
It is now at the stage where it may be considered for inclusion
in OpenJDK. It passes all its tests, and although there is still
some tidying up to do, I think we should move to the next stage.
Thanks,
Andrew.
From stefan.karlsson at oracle.com Thu Jun 19 15:12:24 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 19 Jun 2014 17:12:24 +0200
Subject: RFR: 8047373: Clean the ExceptionCache in one pass
Message-ID: <53A2FDD8.5030501@oracle.com>
Hi all,
Please, review this patch to clean the ExceptionCache in one pass,
instead of re-searching for the element to remove. The patch also makes
nmethod::do_unloading little bit easier to read, IMHO.
http://cr.openjdk.java.net/~stefank/8047373/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8047373
This patch has been used and tested in the G1 Class Unloading project.
thanks,
StefanK
From stefan.karlsson at oracle.com Thu Jun 19 15:36:44 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 19 Jun 2014 17:36:44 +0200
Subject: RFR: 8047326: Add a version of CompiledIC_at that doesn't create
a new RelocIterator
In-Reply-To: <53A2DB59.9050605@oracle.com>
References: <53A2DB59.9050605@oracle.com>
Message-ID: <53A3038C.9020004@oracle.com>
This was meant for the hotspot-dev list. BCC:ing hotspot-gc-dev.
On 2014-06-19 14:45, Stefan Karlsson wrote:
> Hi all,
>
> I have a patch that we have been using in the G1 Class Unloading
> project to lower the remark times. This changes Compiler code, so I
> would like to get feedback from the Compiler team.
>
> http://cr.openjdk.java.net/~stefank/8047362/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8047362
>
> The patch builds upon the patch in:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014358.html
>
>
> Summary from the bug report:
> ---
> Creation of RelocIterators show up high in profiles of the remark
> phase, in the G1 Class Unloading project.
>
> There's a pattern in the nmethod/codecache code to create a
> RelocIterator and then materialize a CompiledIC:
>
> RelocIterator iter(this, low_boundary);
> while(iter.next()) {
> if (iter.type() == relocInfo::virtual_call_type) {
> CompiledIC *ic = CompiledIC_at(iter.reloc());
>
> CompiledIC_at is implemented as:
> new CompiledIC(call_site->code(), nativeCall_at(call_site->addr()));
>
> And one of the first thing CompiledIC::CompiledIC(const nmethod* nm,
> NativeCall* call) does is to create a new RelocIterator:
> ...
> address ic_call = call->instruction_address();
> ...
> RelocIterator iter(nm, ic_call, ic_call+1);
> bool ret = iter.next();
> assert(ret == true, "relocInfo must exist at this address");
> assert(iter.addr() == ic_call, "must find ic_call");
>
> I would like to propose that we pass down the RelocIterator that we
> already have, instead of creating a new.
> ---
>
>
> I've previously received feedback that this seems like reasonable
> thing to do, but that the parameter to the new CompileIC_at should
> take a const RelocIterator* instead of RelocIterator*. I couldn't do
> that without changing a significant amount of Compiler code, so I have
> left it out for now. Any opinions on how to handle that?
>
>
> To give an idea of the performance difference, I temporarily added the
> following code:
> void CodeCache::iterate_through_CIs(int style) {
> int count;
> FOR_ALL_ALIVE_NMETHODS(nm) {
> RelocIterator iter(nm);
> while(iter.next()) {
> if (iter.type() == relocInfo::virtual_call_type ||
> iter.type() == relocInfo::opt_virtual_call_type) {
> if (style > 0) {
> CompiledIC *ic = style == 1 ? CompiledIC_at(&iter) :
> CompiledIC_at(iter.reloc());
> if (ic->ic_destination() == (address)0xdeadb000) {
> gclog_or_tty->print_cr("ShouldNotReachHere");
> }
> }
> }
> }
> }
> }
>
> and then measured how long time it took to execute
> iterate_through_CIs(style) 1000 times with style == {0, 1, 2}.
>
> The results are:
> iterate_through_CIs(0): 1.210833 s // No CompiledICs created
> iterate_through_CIs(1): 1.976557 s // New style
> iterate_through_CIs(2): 9.924209 s // Old style
>
>
> Testing:
> A similar version has been used and thoroughly been tested together
> with the other G1 Class Unloading changes. This exact version has so
> far only been tested with Kitchensink and SpecJVM2008
> compiler.compiler. What test lists would be appropriate to test this
> with?
>
>
> thanks,
> StefanK
>
From coleen.phillimore at oracle.com Thu Jun 19 18:46:51 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 19 Jun 2014 14:46:51 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
References: <539F1066.8080302@oracle.com>
<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
Message-ID: <53A3301B.7070405@oracle.com>
Hi Joel, See below.
On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
> Hi Coleen,
>
> On 16 jun 2014, at 17:42, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> Summary: Add classLoader to java/lang/Class instance for fast access
>>
>> In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers).
>>
>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>
>> There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot.
>>
>> Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>
> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?).
I don't know how to hide the field from reflection. It's a private
final field so you need to get priviledges to make it setAccessible. If
you mean injecting it on the JVM side, the reason for this change is so
that the JIT compilers can inline this call and not have to call into
the JVM to get the class loader.
Thanks,
Coleen
>
> Otherwise looks good.
>
> cheers
> /Joel
From joel.franck at oracle.com Thu Jun 19 19:34:38 2014
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 19 Jun 2014 21:34:38 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A3301B.7070405@oracle.com>
References: <539F1066.8080302@oracle.com>
<6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com>
<53A3301B.7070405@oracle.com>
Message-ID: <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>
Hi,
On 19 jun 2014, at 20:46, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>
>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?).
>
> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader.
>
There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()?
cheers
/Joel
From george.triantafillou at oracle.com Thu Jun 19 19:55:51 2014
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Thu, 19 Jun 2014 15:55:51 -0400
Subject: RFR (M) 8038074: [TESTBUG] Add test for anewarray instruction
with more than 255 dimensions
In-Reply-To: <53A2E523.5070401@oracle.com>
References: <53A21130.6090401@oracle.com> <53A2E523.5070401@oracle.com>
Message-ID: <53A34047.9000001@oracle.com>
Hi Lois,
Thanks for the review!
-George
On 6/19/2014 9:26 AM, Lois Foltan wrote:
> Thanks George for writing this test case. Looks good!
> Lois
>
> On 6/18/2014 6:22 PM, George Triantafillou wrote:
>> Summary: New ASM test to ensure that anewarray bytecode is valid only
>> if it specifies 255 or fewer dimensions.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038074
>> Webrev:
>> http://cr.openjdk.java.net/~gtriantafill/8038074/webrev.00/
>> <http://cr.openjdk.java.net/%7Egtriantafill/8038074/webrev.00/>
>> Testing: JTREG to exercise the added test with JDK 8 and JDK 9
>>
>> Note that the type-inferencing verifier used for <=49.0 ClassFiles
>> detects an anewarray instruction with exactly 255 dimensions and
>> incorrectly issues the "Array with too many dimensions" VerifyError.
>>
>> Thank you,
>>
>> George
>
From mandy.chung at oracle.com Thu Jun 19 20:34:17 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Jun 2014 13:34:17 -0700
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com>
<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>
Message-ID: <53A34949.6040607@oracle.com>
On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
> Hi,
>
> On 19 jun 2014, at 20:46, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?).
>> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader.
>>
> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()?
>
There are many getter methods that returns a private final field.
I'm not sure if hiding the field is necessary nor a good precedence
to set. Accessing a private field requires "accessDeclaredMember"
permission although it's a different security check (vs "getClassLoader"
permission). Arguably before this new classLoader field, one could
call Class.getClassLoader0() via reflection to get a hold of class
loader.
Perhaps you are concerned that the "accessDeclaredMember" permission
is too coarse-grained? I think the security team is looking into
the improvement in that regards.
Mandy
From joel.franck at oracle.com Thu Jun 19 20:53:34 2014
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 19 Jun 2014 22:53:34 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A34949.6040607@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com>
<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>
<53A34949.6040607@oracle.com>
Message-ID: <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
Hi Mandy,
On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>> Hi,
>>
>> On 19 jun 2014, at 20:46, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?).
>>> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader.
>>>
>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()?
>>
> There are many getter methods that returns a private final field.
> I'm not sure if hiding the field is necessary nor a good precedence
> to set. Accessing a private field requires "accessDeclaredMember"
> permission although it's a different security check (vs "getClassLoader"
> permission). Arguably before this new classLoader field, one could
> call Class.getClassLoader0() via reflection to get a hold of class
> loader.
>
> Perhaps you are concerned that the "accessDeclaredMember" permission
> is too coarse-grained? I think the security team is looking into
> the improvement in that regards.
I think I?m a bit worried about two things, first as you wrote, ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since you could get the class loader through getClassLoader0() that shouldn?t be a new issue.
The second thing is that IIRC there are ways to set a final field after initialization. I?m not sure we need to care about that either if you need Unsafe to do it.
cheers
/Joel
From coleen.phillimore at oracle.com Thu Jun 19 20:54:49 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 19 Jun 2014 16:54:49 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A34949.6040607@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com>
<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>
<53A34949.6040607@oracle.com>
Message-ID: <53A34E19.4030707@oracle.com>
On 6/19/14, 4:34 PM, Mandy Chung wrote:
> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>> Hi,
>>
>> On 19 jun 2014, at 20:46, Coleen Phillimore
>> <coleen.phillimore at oracle.com> wrote:
>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>> Have you considered hiding the Class.classLoader field from
>>>> reflection? I?m not sure it is necessary but I?m not to keen on the
>>>> idea of people poking at this field with Unsafe (which should go
>>>> away in 9 but ?).
>>> I don't know how to hide the field from reflection. It's a private
>>> final field so you need to get priviledges to make it
>>> setAccessible. If you mean injecting it on the JVM side, the reason
>>> for this change is so that the JIT compilers can inline this call
>>> and not have to call into the JVM to get the class loader.
>>>
>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a
>> field from being found using reflection. It might very well be the
>> case that private and final is enough, I haven?t thought this through
>> 100%. On the other hand, is there a reason to give users access
>> through the field instead of having to use Class.getClassLoader()?
>>
> There are many getter methods that returns a private final field.
> I'm not sure if hiding the field is necessary nor a good precedence
> to set. Accessing a private field requires "accessDeclaredMember"
> permission although it's a different security check (vs "getClassLoader"
> permission). Arguably before this new classLoader field, one could
> call Class.getClassLoader0() via reflection to get a hold of class
> loader.
Yes, thank you Mandy.
Coleen
>
> Perhaps you are concerned that the "accessDeclaredMember" permission
> is too coarse-grained? I think the security team is looking into
> the improvement in that regards.
>
> Mandy
>
From coleen.phillimore at oracle.com Thu Jun 19 21:09:57 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 19 Jun 2014 17:09:57 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com>
<92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com>
<53A34949.6040607@oracle.com>
<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
Message-ID: <53A351A5.8000109@oracle.com>
On 6/19/14, 4:53 PM, Joel Borggr?n-Franck wrote:
> Hi Mandy,
>
> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>
>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>> Hi,
>>>
>>> On 19 jun 2014, at 20:46, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?).
>>>> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader.
>>>>
>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()?
>>>
>> There are many getter methods that returns a private final field.
>> I'm not sure if hiding the field is necessary nor a good precedence
>> to set. Accessing a private field requires "accessDeclaredMember"
>> permission although it's a different security check (vs "getClassLoader"
>> permission). Arguably before this new classLoader field, one could
>> call Class.getClassLoader0() via reflection to get a hold of class
>> loader.
>>
>> Perhaps you are concerned that the "accessDeclaredMember" permission
>> is too coarse-grained? I think the security team is looking into
>> the improvement in that regards.
> I think I?m a bit worried about two things, first as you wrote, ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since you could get the class loader through getClassLoader0() that shouldn?t be a new issue.
>
> The second thing is that IIRC there are ways to set a final field after initialization. I?m not sure we need to care about that either if you need Unsafe to do it.
>
> cheers
> /Joel
So hiding this field from reflection and Unsafe doesn't seem like
something we would need to do. If the field is the protectionDomain
associated with this class, would that be different?
Coleen
From david.holmes at oracle.com Fri Jun 20 03:01:22 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Jun 2014 13:01:22 +1000
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com>
<105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
Message-ID: <53A3A402.2060501@oracle.com>
On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
> Hi Mandy,
>
> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>
>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>> Hi,
>>>
>>> On 19 jun 2014, at 20:46, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>> Have you considered hiding the Class.classLoader field from reflection? I?m not sure it is necessary but I?m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but ?).
>>>> I don't know how to hide the field from reflection. It's a private final field so you need to get priviledges to make it setAccessible. If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader.
>>>>
>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven?t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()?
>>>
>> There are many getter methods that returns a private final field.
>> I'm not sure if hiding the field is necessary nor a good precedence
>> to set. Accessing a private field requires "accessDeclaredMember"
>> permission although it's a different security check (vs "getClassLoader"
>> permission). Arguably before this new classLoader field, one could
>> call Class.getClassLoader0() via reflection to get a hold of class
>> loader.
>>
>> Perhaps you are concerned that the "accessDeclaredMember" permission
>> is too coarse-grained? I think the security team is looking into
>> the improvement in that regards.
>
> I think I?m a bit worried about two things, first as you wrote, ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since you could get the class loader through getClassLoader0() that shouldn?t be a new issue.
>
> The second thing is that IIRC there are ways to set a final field after initialization. I?m not sure we need to care about that either if you need Unsafe to do it.
Normal reflection can set a final field if you can successfully call
setAccessible(true) on the Field object.
David
-----
> cheers
> /Joel
>
From david.holmes at oracle.com Fri Jun 20 03:08:36 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Jun 2014 13:08:36 +1000
Subject: RFR 8043541: 'fastdebug' is printed twice in java -version
In-Reply-To: <53A2779A.70201@oracle.com>
References: <53A2779A.70201@oracle.com>
Message-ID: <53A3A5B4.5080707@oracle.com>
Looks good to me.
Thanks,
David
On 19/06/2014 3:39 PM, Alejandro E Murillo wrote:
> Can I get a review for this change?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
> webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
>
> Note that this was discovered through nightly testing, but is not per se
> causing
> any failures. It only affects full non product JDK builds. It does not
> affect hotspot
> only builds.
>
> The bug was initially filed as confidential, it's a p4, if you can't see
> the description, here it is:
> "After the format of the hotspot version string was changed now
> 'fastdebug' is showing twice
> in the hotspot version output of 'java -version' ONLY on Full non
> product JDK builds as shown below:
>
> java version "1.9.0-ea-fastdebug"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
> Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
> mixed mode)
> -----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^
>
>
> Background about the fix:
> In a nutshell, with this fix, the build target is added to
> HOTSPOT_RELEASE_VERSION,
> on hotspot/make/defs.make, and on Hotspot ONLY builds, instead of
> passing it to
> vm_version.cpp through HOTSPOT_TARGET_BUILD.
>
> HOWEVER, given the way the project to build hotspot (only) with Visual
> Studio is created,
> it is not possible to add that (HOTSPOT_TARGET_BUILD) to
> HOTSPOT_RELEASE_VERSION
> when the VS project is created, so HOTSPOT_TARGET_BUILD is still passed
> to vm_version.cpp,
> on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
> building
> with Visual studio. Building windows with gnu make (as jprt does) will
> work as in other platforms.
>
> I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to vm_version.cpp
> altogether, but I suspect it
> was done that way to append the target build on non product builds when
> using Visual studio.
> If someone is familiar with the VS create.bat script and visual studio
> in general, please
> take a look and see if there's a way to pass that info at project
> creation time, so that
> we can completely get rid of passing HOTSPOT_TARGET_BUILD to
> vm_version.cpp.
> Please file an RFE if necessary.
>
> With this solution:
> (a) For FULL JDK builds, 'fastdebug' will not be duplicated (bug being
> fixed) on those builds.
> (b) And for JUST hotspot only, non product builds, the output format for
> the hotspot
> version will slightly change from (see ^^^^^^ below):
>
> java version "1.9.0-ea-fastdebug"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
> Java HotSpot(TM) Server VM (build
> 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug, mixed
> mode)
> ------------------------------------------------------------------------------------------^^^^^^^^^
>
>
> TO:
>
> java version "1.9.0-ea-fastdebug"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
> Java HotSpot(TM) Server VM (build
> 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB, mixed
> mode)
> ----------------------------------------^^^^^^^^^----------------------------------------------------
>
>
>
> Basically 'fastdebug' is now added right after the jdk version, before
> 'internal',
> in the hotspot portion, instead of at the end. Product builds are not
> affected at all.
> note, those are outputs from hs only JPRT builds. Non JPRT hs only
> builds may not have
> anything after 'internal' (by default).
>
> thanks
>
From alejandro.murillo at oracle.com Fri Jun 20 05:45:29 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 19 Jun 2014 23:45:29 -0600
Subject: RFR 8043541: 'fastdebug' is printed twice in java -version
In-Reply-To: <53A3A5B4.5080707@oracle.com>
References: <53A2779A.70201@oracle.com> <53A3A5B4.5080707@oracle.com>
Message-ID: <53A3CA79.80403@oracle.com>
Thanks David!
Alejandro
On 6/19/2014 9:08 PM, David Holmes wrote:
> Looks good to me.
>
> Thanks,
> David
>
> On 19/06/2014 3:39 PM, Alejandro E Murillo wrote:
>> Can I get a review for this change?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
>> webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
>>
>> Note that this was discovered through nightly testing, but is not per se
>> causing
>> any failures. It only affects full non product JDK builds. It does not
>> affect hotspot
>> only builds.
>>
>> The bug was initially filed as confidential, it's a p4, if you can't see
>> the description, here it is:
>> "After the format of the hotspot version string was changed now
>> 'fastdebug' is showing twice
>> in the hotspot version output of 'java -version' ONLY on Full non
>> product JDK builds as shown below:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
>> Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
>> mixed mode)
>> -----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^
>>
>>
>>
>> Background about the fix:
>> In a nutshell, with this fix, the build target is added to
>> HOTSPOT_RELEASE_VERSION,
>> on hotspot/make/defs.make, and on Hotspot ONLY builds, instead of
>> passing it to
>> vm_version.cpp through HOTSPOT_TARGET_BUILD.
>>
>> HOWEVER, given the way the project to build hotspot (only) with Visual
>> Studio is created,
>> it is not possible to add that (HOTSPOT_TARGET_BUILD) to
>> HOTSPOT_RELEASE_VERSION
>> when the VS project is created, so HOTSPOT_TARGET_BUILD is still passed
>> to vm_version.cpp,
>> on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
>> building
>> with Visual studio. Building windows with gnu make (as jprt does) will
>> work as in other platforms.
>>
>> I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to vm_version.cpp
>> altogether, but I suspect it
>> was done that way to append the target build on non product builds when
>> using Visual studio.
>> If someone is familiar with the VS create.bat script and visual studio
>> in general, please
>> take a look and see if there's a way to pass that info at project
>> creation time, so that
>> we can completely get rid of passing HOTSPOT_TARGET_BUILD to
>> vm_version.cpp.
>> Please file an RFE if necessary.
>>
>> With this solution:
>> (a) For FULL JDK builds, 'fastdebug' will not be duplicated (bug being
>> fixed) on those builds.
>> (b) And for JUST hotspot only, non product builds, the output format for
>> the hotspot
>> version will slightly change from (see ^^^^^^ below):
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug, mixed
>> mode)
>> ------------------------------------------------------------------------------------------^^^^^^^^^
>>
>>
>>
>> TO:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB, mixed
>> mode)
>> ----------------------------------------^^^^^^^^^----------------------------------------------------
>>
>>
>>
>>
>> Basically 'fastdebug' is now added right after the jdk version, before
>> 'internal',
>> in the hotspot portion, instead of at the end. Product builds are not
>> affected at all.
>> note, those are outputs from hs only JPRT builds. Non JPRT hs only
>> builds may not have
>> anything after 'internal' (by default).
>>
>> thanks
>>
--
Alejandro
From coleen.phillimore at oracle.com Fri Jun 20 15:06:30 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 20 Jun 2014 11:06:30 -0400
Subject: RFR (M) 8038074: [TESTBUG] Add test for anewarray instruction
with more than 255 dimensions
In-Reply-To: <53A21130.6090401@oracle.com>
References: <53A21130.6090401@oracle.com>
Message-ID: <53A44DF6.3050201@oracle.com>
The test looks good.
Coleen
On 6/18/14, 6:22 PM, George Triantafillou wrote:
> Summary: New ASM test to ensure that anewarray bytecode is valid only
> if it specifies 255 or fewer dimensions.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8038074
> Webrev:
> http://cr.openjdk.java.net/~gtriantafill/8038074/webrev.00/
> <http://cr.openjdk.java.net/%7Egtriantafill/8038074/webrev.00/>
> Testing: JTREG to exercise the added test with JDK 8 and JDK 9
>
> Note that the type-inferencing verifier used for <=49.0 ClassFiles
> detects an anewarray instruction with exactly 255 dimensions and
> incorrectly issues the "Array with too many dimensions" VerifyError.
>
> Thank you,
>
> George
From george.triantafillou at oracle.com Fri Jun 20 15:15:52 2014
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Fri, 20 Jun 2014 11:15:52 -0400
Subject: RFR (M) 8038074: [TESTBUG] Add test for anewarray instruction
with more than 255 dimensions
In-Reply-To: <53A44DF6.3050201@oracle.com>
References: <53A21130.6090401@oracle.com> <53A44DF6.3050201@oracle.com>
Message-ID: <53A45028.8080800@oracle.com>
Thanks Coleen.
-George
On 6/20/2014 11:06 AM, Coleen Phillimore wrote:
>
> The test looks good.
>
> Coleen
>
> On 6/18/14, 6:22 PM, George Triantafillou wrote:
>> Summary: New ASM test to ensure that anewarray bytecode is valid only
>> if it specifies 255 or fewer dimensions.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038074
>> Webrev:
>> http://cr.openjdk.java.net/~gtriantafill/8038074/webrev.00/
>> <http://cr.openjdk.java.net/%7Egtriantafill/8038074/webrev.00/>
>> Testing: JTREG to exercise the added test with JDK 8 and JDK 9
>>
>> Note that the type-inferencing verifier used for <=49.0 ClassFiles
>> detects an anewarray instruction with exactly 255 dimensions and
>> incorrectly issues the "Array with too many dimensions" VerifyError.
>>
>> Thank you,
>>
>> George
>
From kim.barrett at oracle.com Fri Jun 20 18:03:32 2014
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 20 Jun 2014 14:03:32 -0400
Subject: PATCH: using mixed types in MIN2/MAX2 functions
In-Reply-To: <20140619150654.cf6c68f626234f01295fec61@danny.cz>
References: <20140612110513.d59301a5c21f3000aa4973d1@danny.cz>
<5399F826.4060409@oracle.com> <539A0454.5030906@oracle.com>
<20140613095511.5fae7c4b483bb65f073e5628@danny.cz>
<539AEA4D.8020204@oracle.com>
<20140613145531.559f6d943ef097550580a1f6@danny.cz>
<539E8F41.6070001@oracle.com>
<20140616091702.28b895ce918bdf4c58d2506f@danny.cz>
<539ED1EE.30107@oracle.com> <539EFCE5.9020108@oracle.com>
<20140616162130.ac9bec274c625241bb7fd18d@danny.cz>
<539F0CA0.3010309@oracle.com>
<20140616182920.baccf0cc83debbe522189688@danny.cz>
<539F22E0.2080202@oracle.com>
<20140618085537.0cc3e3e85856ae67c491c88e@danny.cz>
<53A18A50.50001@oracle.com> <53A2DDD8.4010605@oracle.com>
<20140619150654.cf6c68f626234f01295fec61@danny.cz>
Message-ID: <F420349B-19EC-46EC-8E18-486D0D8B99AD@oracle.com>
On Jun 19, 2014, at 9:06 AM, Dan Hor?k <dan at danny.cz> wrote:
>
> On Thu, 19 Jun 2014 14:55:52 +0200
> Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>> Can you explain more in detail why it is not possible to specialize
>> the MIN2 and MAX2 functions? You are probably correct, because when I
>> read the comment in the code it says:
>>
>>
>> // It is necessary to use templates here. Having normal overloaded
>> // functions does not work because it is necessary to provide both 32-
>> // and 64-bit overloaded functions, which does not work, and having
>> // explicitly-typed versions of these routines (i.e., MAX2I, MAX2L)
>> // will be even more error-prone than macros.
>> template<class T> inline T MAX2(T a, T b) { return (a >
>> b) ? a : b; }
>>
>>
>> This kind of says what you also said. That it is not possible, but it
>> does not really explain why.
>>
>> Can you explain why we can have definitions like:
>>
>> inline uint MAX2(uint a, size_t b)
>> inline uint MAX2(size_t a, uint b)
>
> if I remember correctly from my previous experience, these 2 definition
> conflict with the existing
> inline uint MAX2(uint a, uint b)
> on platforms where size_t == uint. But I might be wrong, the easiest we
> can do, is to try add them. Or we could add the new definitions only
> for s390 with #if defined(__s390__) && ! defined(__s390x__). Or maybe
> there is another way to add them only when size_t != uint. A C++ expert
> is required :-)
This isn?t too difficult. The tests at the end should of course be turned into real test cases.
Requires
- <limits>
- std::numeric_limits<T>::is_specialized
- for specialized types
- std::numeric_limits<T>::is_integer
- std::numeric_limits<T>::is_signed
- partial template specialization
- SFINAE for function return types
I have no idea whether all of our toolchains support all that. I?ve heard of some
strange defects around numeric_limits with some (older) toolchains. For example,
boost provides
BOOST_NO_LIMIT - does not provide <limits>
BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
std::numeric_limits<T>::is_signed and similar are not available at compile-time.
Neither of those seem to be applicable to any toolchain relevant to jdk code though.
I also don't know how folks feel about non-trivial template usage.
???????
#include <limits>
// MIN2/MAX2(a, b) compare a and b and return the lesser/greater.
//
// a and b must either
//
// - be of the same type, in which case the result is of that type, or
//
// - both be of integer types with the same signed-ness, in which case the
// result is the larger of those two types.
template<typename T, typename U, bool T_Smaller = (sizeof(T) < sizeof(U))>
struct MINMAX2_result_differ_choose { typedef U type; };
template<typename T, typename U>
struct MINMAX2_result_differ_choose<T, U, false> { typedef T type; };
template<typename T, typename U,
bool T_Integer = std::numeric_limits<T>::is_specialized,
bool U_Integer = std::numeric_limits<U>::is_specialized>
struct MINMAX2_result_differ { };
template<typename T, typename U,
bool T_Integer = std::numeric_limits<T>::is_integer,
bool U_Integer = std::numeric_limits<U>::is_integer,
bool SameSigned = (std::numeric_limits<T>::is_signed
== std::numeric_limits<U>::is_signed)>
struct MINMAX2_result_differ_aux { };
template<typename T, typename U>
struct MINMAX2_result_differ_aux<T, U, true, true, true>
: public MINMAX2_result_differ_choose<T, U>
{ };
template<typename T, typename U>
struct MINMAX2_result_differ<T, U, true, true>
: public MINMAX2_result_differ_aux<T, U>
{ };
template<typename T, typename U>
struct MINMAX2_result_type
: public MINMAX2_result_differ<T, U>
{ };
template<typename T>
struct MINMAX2_result_type<T, T> {
typedef T type;
};
template<typename T, typename U>
inline typename MINMAX2_result_type<T, U>::type MAX2(T a, U b) {
// note: if T & U are different integral types, terniary operator will
// perform implicit promotion of the smaller to the larger.
return a > b ? a : b;
}
template<typename T, typename U>
inline typename MINMAX2_result_type<T, U>::type MIN2(T a, U b) {
// note: if T & U are different integral types, terniary operator will
// perform implicit promotion of the smaller to the larger.
return a < b ? a : b;
}
// TESTS
typedef unsigned int uint;
typedef unsigned int uint_size_t;
typedef unsigned long ulong_size_t;
uint max_same1(uint a, uint_size_t b) { return MAX2(a, b); }
uint max_same2(uint_size_t a, uint b) { return MAX2(a, b); }
uint min_same1(uint a, uint_size_t b) { return MIN2(a, b); }
uint min_same2(uint_size_t a, uint b) { return MIN2(a, b); }
ulong_size_t max_diff1(uint a, ulong_size_t b) { return MAX2(a, b); }
ulong_size_t max_diff2(ulong_size_t a, uint b) { return MAX2(a, b); }
ulong_size_t min_diff1(uint a, ulong_size_t b) { return MIN2(a, b); }
ulong_size_t min_diff2(ulong_size_t a, uint b) { return MIN2(a, b); }
ulong_size_t max_ulong_size_t(ulong_size_t a, ulong_size_t b) {
return MAX2(a, b);
}
uint_size_t max_uing_size_t(uint_size_t a, uint_size_t b) {
return MAX2(a, b);
}
ulong_size_t min_ulong_size_t(ulong_size_t a, ulong_size_t b) {
return MIN2(a, b);
}
uint_size_t min_uing_size_t(uint_size_t a, uint_size_t b) {
return MIN2(a, b);
}
// these aren't supposed to compile
// float max_float1(uint a, float b) { return MAX2(a, b); }
// float max_float2(float a, uint b) { return MAX2(a, b); }
// float min_float1(uint a, float b) { return MIN2(a, b); }
// float min_float2(float a, uint b) { return MIN2(a, b); }
// uint max_int1(uint a, int b) { return MAX2(a, b); }
// uint max_int2(int a, uint b) { return MAX2(a, b); }
// uint min_int1(uint a, int b) { return MIN2(a, b); }
// uint min_int2(int a, uint b) { return MIN2(a, b); }
// uint max_long1(uint a, long b) { return MAX2(a, b); }
// uint max_long2(long a, uint b) { return MAX2(a, b); }
// uint min_long1(uint a, long b) { return MIN2(a, b); }
// uint min_long2(long a, uint b) { return MIN2(a, b); }
From kim.barrett at oracle.com Fri Jun 20 18:51:23 2014
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 20 Jun 2014 14:51:23 -0400
Subject: RFR: 8047373: Clean the ExceptionCache in one pass
In-Reply-To: <53A2FDD8.5030501@oracle.com>
References: <53A2FDD8.5030501@oracle.com>
Message-ID: <E31B9B8E-08BC-4591-BF40-3EA4E609839E@oracle.com>
Not sure my opinion counts for much yet, but this looks good to me.
On Jun 19, 2014, at 11:12 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>
> Hi all,
>
> Please, review this patch to clean the ExceptionCache in one pass, instead of re-searching for the element to remove. The patch also makes nmethod::do_unloading little bit easier to read, IMHO.
>
> http://cr.openjdk.java.net/~stefank/8047373/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8047373
>
> This patch has been used and tested in the G1 Class Unloading project.
>
> thanks,
> StefanK
From jon.masamitsu at oracle.com Fri Jun 20 23:35:59 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 20 Jun 2014 16:35:59 -0700
Subject: RFR: 8047373: Clean the ExceptionCache in one pass
In-Reply-To: <53A2FDD8.5030501@oracle.com>
References: <53A2FDD8.5030501@oracle.com>
Message-ID: <53A4C55F.60906@oracle.com>
Change looks good.
Reviewed.
Jon
On 6/19/2014 8:12 AM, Stefan Karlsson wrote:
> Hi all,
>
> Please, review this patch to clean the ExceptionCache in one pass,
> instead of re-searching for the element to remove. The patch also
> makes nmethod::do_unloading little bit easier to read, IMHO.
>
> http://cr.openjdk.java.net/~stefank/8047373/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8047373
>
> This patch has been used and tested in the G1 Class Unloading project.
>
> thanks,
> StefanK
>
From daniel.daugherty at oracle.com Sat Jun 21 01:09:49 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 20 Jun 2014 19:09:49 -0600
Subject: RFR 8043541: 'fastdebug' is printed twice in java -version
In-Reply-To: <53A2779A.70201@oracle.com>
References: <53A2779A.70201@oracle.com>
Message-ID: <53A4DB5D.3010303@oracle.com>
On 6/18/14 11:39 PM, Alejandro E Murillo wrote:
> Can I get a review for this change?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
> webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
make/aix/makefiles/vm.make
No comments.
make/bsd/makefiles/vm.make
No comments.
make/defs.make
No comments.
make/linux/makefiles/vm.make
No comments.
make/solaris/makefiles/vm.make
No comments.
make/windows/projectfiles/common/Makefile
No comments.
src/share/vm/runtime/vm_version.cpp
It took me several readings to figure out what you're doing
here. I'm not sure what my brain was doing wrong or how to
clear it up for anyone else.
Thumbs up.
Dan
>
> Note that this was discovered through nightly testing, but is not per
> se causing
> any failures. It only affects full non product JDK builds. It does not
> affect hotspot
> only builds.
>
> The bug was initially filed as confidential, it's a p4, if you can't
> see the description, here it is:
> "After the format of the hotspot version string was changed now
> 'fastdebug' is showing twice
> in the hotspot version output of 'java -version' ONLY on Full non
> product JDK builds as shown below:
>
> java version "1.9.0-ea-fastdebug"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
> Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
> mixed mode)
> -----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^
>
>
> Background about the fix:
> In a nutshell, with this fix, the build target is added to
> HOTSPOT_RELEASE_VERSION,
> on hotspot/make/defs.make, and on Hotspot ONLY builds, instead of
> passing it to
> vm_version.cpp through HOTSPOT_TARGET_BUILD.
>
> HOWEVER, given the way the project to build hotspot (only) with Visual
> Studio is created,
> it is not possible to add that (HOTSPOT_TARGET_BUILD) to
> HOTSPOT_RELEASE_VERSION
> when the VS project is created, so HOTSPOT_TARGET_BUILD is still
> passed to vm_version.cpp,
> on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
> building
> with Visual studio. Building windows with gnu make (as jprt does) will
> work as in other platforms.
>
> I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to
> vm_version.cpp altogether, but I suspect it
> was done that way to append the target build on non product builds
> when using Visual studio.
> If someone is familiar with the VS create.bat script and visual studio
> in general, please
> take a look and see if there's a way to pass that info at project
> creation time, so that
> we can completely get rid of passing HOTSPOT_TARGET_BUILD to
> vm_version.cpp.
> Please file an RFE if necessary.
>
> With this solution:
> (a) For FULL JDK builds, 'fastdebug' will not be duplicated (bug
> being fixed) on those builds.
> (b) And for JUST hotspot only, non product builds, the output format
> for the hotspot
> version will slightly change from (see ^^^^^^ below):
>
> java version "1.9.0-ea-fastdebug"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
> Java HotSpot(TM) Server VM (build
> 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug,
> mixed mode)
> ------------------------------------------------------------------------------------------^^^^^^^^^
>
>
> TO:
>
> java version "1.9.0-ea-fastdebug"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
> Java HotSpot(TM) Server VM (build
> 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB,
> mixed mode)
> ----------------------------------------^^^^^^^^^----------------------------------------------------
>
>
>
> Basically 'fastdebug' is now added right after the jdk version, before
> 'internal',
> in the hotspot portion, instead of at the end. Product builds are not
> affected at all.
> note, those are outputs from hs only JPRT builds. Non JPRT hs only
> builds may not have
> anything after 'internal' (by default).
>
> thanks
>
From david.holmes at oracle.com Sat Jun 21 06:23:03 2014
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 21 Jun 2014 16:23:03 +1000
Subject: RFR 8043541: 'fastdebug' is printed twice in java -version
In-Reply-To: <53A4DB5D.3010303@oracle.com>
References: <53A2779A.70201@oracle.com> <53A4DB5D.3010303@oracle.com>
Message-ID: <53A524C7.4010801@oracle.com>
On 21/06/2014 11:09 AM, Daniel D. Daugherty wrote:
>
> On 6/18/14 11:39 PM, Alejandro E Murillo wrote:
>> Can I get a review for this change?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
>> webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
>
> make/aix/makefiles/vm.make
> No comments.
>
> make/bsd/makefiles/vm.make
> No comments.
>
> make/defs.make
> No comments.
>
> make/linux/makefiles/vm.make
> No comments.
>
> make/solaris/makefiles/vm.make
> No comments.
>
> make/windows/projectfiles/common/Makefile
> No comments.
>
> src/share/vm/runtime/vm_version.cpp
> It took me several readings to figure out what you're doing
> here. I'm not sure what my brain was doing wrong or how to
> clear it up for anyone else.
I had the same issue. Inverting the logic might be clearer:
if VS and not product
do special stuff
else
do normal stuff
but I'll leave it to Alejandro as to whether it is worth the effort to
change.
David
> Thumbs up.
>
>
> Dan
>
>
>>
>> Note that this was discovered through nightly testing, but is not per
>> se causing
>> any failures. It only affects full non product JDK builds. It does not
>> affect hotspot
>> only builds.
>>
>> The bug was initially filed as confidential, it's a p4, if you can't
>> see the description, here it is:
>> "After the format of the hotspot version string was changed now
>> 'fastdebug' is showing twice
>> in the hotspot version output of 'java -version' ONLY on Full non
>> product JDK builds as shown below:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
>> Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
>> mixed mode)
>> -----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^
>>
>>
>> Background about the fix:
>> In a nutshell, with this fix, the build target is added to
>> HOTSPOT_RELEASE_VERSION,
>> on hotspot/make/defs.make, and on Hotspot ONLY builds, instead of
>> passing it to
>> vm_version.cpp through HOTSPOT_TARGET_BUILD.
>>
>> HOWEVER, given the way the project to build hotspot (only) with Visual
>> Studio is created,
>> it is not possible to add that (HOTSPOT_TARGET_BUILD) to
>> HOTSPOT_RELEASE_VERSION
>> when the VS project is created, so HOTSPOT_TARGET_BUILD is still
>> passed to vm_version.cpp,
>> on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
>> building
>> with Visual studio. Building windows with gnu make (as jprt does) will
>> work as in other platforms.
>>
>> I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to
>> vm_version.cpp altogether, but I suspect it
>> was done that way to append the target build on non product builds
>> when using Visual studio.
>> If someone is familiar with the VS create.bat script and visual studio
>> in general, please
>> take a look and see if there's a way to pass that info at project
>> creation time, so that
>> we can completely get rid of passing HOTSPOT_TARGET_BUILD to
>> vm_version.cpp.
>> Please file an RFE if necessary.
>>
>> With this solution:
>> (a) For FULL JDK builds, 'fastdebug' will not be duplicated (bug
>> being fixed) on those builds.
>> (b) And for JUST hotspot only, non product builds, the output format
>> for the hotspot
>> version will slightly change from (see ^^^^^^ below):
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug,
>> mixed mode)
>> ------------------------------------------------------------------------------------------^^^^^^^^^
>>
>>
>> TO:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB,
>> mixed mode)
>> ----------------------------------------^^^^^^^^^----------------------------------------------------
>>
>>
>>
>> Basically 'fastdebug' is now added right after the jdk version, before
>> 'internal',
>> in the hotspot portion, instead of at the end. Product builds are not
>> affected at all.
>> note, those are outputs from hs only JPRT builds. Non JPRT hs only
>> builds may not have
>> anything after 'internal' (by default).
>>
>> thanks
>>
>
From dyb22700 at gmail.com Mon Jun 23 08:58:47 2014
From: dyb22700 at gmail.com (Dylan BRADFORD)
Date: Mon, 23 Jun 2014 10:58:47 +0200
Subject: Fwd: TR: JDK-6988950 : JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)
References: <97AC907E22BD924289D66253EB2A541E984BE0@H146.questel.fr>
Message-ID: <7DB4789B-A2D5-401D-8FCD-BF492CCB1F62@gmail.com>
Dear Hotspot-dev,
I transfer this information on your regards to help resolving this issue.
BR,
Dylan.
Envoy? de mon iPhone
D?but du message transf?r? :
> Exp?diteur: Dylan Bradford <dbradford at questel.com>
> Date: 23 juin 2014 10:56:13 UTC+02:00
> Destinataire: "dyb22700 at gmail.com" <dyb22700 at gmail.com>
> Objet: TR: JDK-6988950 : JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)
>
>
>
> De : Dylan Bradford
> Envoy? : vendredi 20 juin 2014 08:46
> ? : 'help at openjdk.java.net'
> Objet : JDK-6988950 : JDWP exit error JVMTI_ERROR_WRONG_PHASE(112)
>
> Dear openjdk,
>
> I had the same problem occuring in my Eclipse Kepler recently under mavenized project, and I found the difference in my project as the validation preference file being added to my svn control, so by deleting it my compilation is working fine and the error disappear !
>
> So I guess this is a entry search to solve and fix the bug, hopefully.
>
> BR,
>
> Dylan Brardford.
From goetz.lindenmaier at sap.com Mon Jun 23 09:54:30 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 23 Jun 2014 09:54:30 +0000
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <5396BFF1.7080305@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
<53902C7E.5010108@oracle.com>
<4295855A5C1DE049A61835A1887419CC2CEC706B@DEWDFEMB12A.global.corp.sap>
<5396BFF1.7080305@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CED728D@DEWDFEMB12A.global.corp.sap>
Hi Stefan,
thanks for the review!
I still need a sponsor for this.
Could you please push this change?
Thanks,
Goetz.
-----Original Message-----
From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
Sent: Dienstag, 10. Juni 2014 10:21
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
On 2014-06-05 22:23, Lindenmaier, Goetz wrote:
> Hi Stefan,
>
> thanks for the thorough review!
>
>> Thanks again for cleaning up the include files.
> I checked the other includes, I would like to do this for os_<os>.inline.hpp, too.
> That include cascade is shorter, but used in around 30 files.
> Other more prominent cascades are
> bytes_<cpu>.hpp (12 cascades),
> ad_<cpu>.hpp (10 cascades),
> nativeInst_<cpu>.hpp (8)
> vmreg.inline_<cpu>.hpp (7)
> As we have another 3 cpus (zArch, parisc, ia64), that would clean up our code
> nicely ;)
>
> Back to this change:
>
> I moved the Atomics in StringDedup.hpp as you requested.
> I removed the include in markSweep.inline.hpp.
> I moved the include in oop.pcgc.inline.hpp up.
> I moved the debug methods in gcLocker.hpp to the cpp file.
>
>> This is a lot of noise just to get rid of a call to the the
>> CompiledICHolder constructor in product builds. Is it really worth it?
> I think not. Moved to cpp file.
>
> About adding the header to precompiled.hpp: I don't really care,
> I just follow the current pattern. As there were no other comments
> on your request in the last change, I removed it this time.
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.01
Thanks.
Looks good to me.
StefanK
>
> Best regards,
> Goetz.
>
>
> -----Original Message-----
> From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
> Sent: Donnerstag, 5. Juni 2014 10:38
> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
>
> Hi Goetz,
>
> Thanks again for cleaning up the include files.
>
> On 2014-06-04 15:59, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I would like to do another change cleaning up the includes of
>> .inline.hpp files from the os_cpu directories.
>>
>> Please review and test this change. I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.hpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.cpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupQueue.cpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp.udiff.html
>
> I think it would be good to move the Atomic calls out from the
> g1StringDedup.hpp to g1StringDedup.cpp. I talked to Per, the author of
> StringDedup, and he would be fine with that move.
> I moved the debug methods in gcLocker.hpp to the cpp file.
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.frames.html
>
> 32 #if INCLUDE_ALL_GCS
> 33 #include "gc_implementation/g1/g1StringDedup.hpp"
> 34 #include "gc_implementation/parallelScavenge/psParallelCompact.hpp"
> 35 #include "runtime/atomic.inline.hpp"
> 36 #endif // INCLUDE_ALL_GCS
>
> Why was this include added? Was it becuase g1StringDedup.hpp was added?
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/mutableSpace.cpp.frames.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/oop.pcgc.inline.hpp.frames.html
>
> 25 #include "precompiled.hpp"
> 26 #include "utilities/macros.hpp"
> 27 #if INCLUDE_ALL_GCS
> 28 #include "gc_implementation/shared/mutableSpace.hpp"
> 29 #include "gc_implementation/shared/spaceDecorator.hpp"
> 30 #include "oops/oop.inline.hpp"
> 31 #include "runtime/safepoint.hpp"
> 32 #include "runtime/thread.hpp"
> 33 #endif // INCLUDE_ALL_GCS
> 34 #include "runtime/atomic.inline.hpp"
>
> Could you place the new includes together with the includes before the
> INCLUDE_ALL_GCS block?
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.hpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.inline.hpp.udiff.html
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/runtime/safepoint.cpp.udiff.html
>
> + inline static void increment_debug_jni_lock_count();
> + inline static void decrement_debug_jni_lock_count();
>
> This is debugging code, so it would be better to move it to the .cpp file.
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/compiledICHolder.hpp.udiff.html
>
> 54 #ifdef ASSERT
> 55 CompiledICHolder(Method* method, Klass* klass);
> 56 #else
> 57 CompiledICHolder(Method* method, Klass* klass)
> 58 : _holder_method(method), _holder_klass(klass) {};
> 59 #endif
> 60
> 61 ~CompiledICHolder() NOT_DEBUG_RETURN;
>
> This is a lot of noise just to get rid of a call to the the
> CompiledICHolder constructor in product builds. Is it really worth it?
>
>
> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/precompiled/precompiled.hpp.udiff.html
>
> # include "runtime/atomic.hpp"
> +# include "runtime/atomic.inline.hpp"
>
> I still think this is a bad idea. It will just make it more likely that
> someone building with precompiled headers will forget to include
> atomic.inline.hpp, and we would have to clean it up later when we found
> out that it breaks some platform outside of Oracle's test matrix.
>
> thanks,
> StefanK
>
>> This change improves the usage of the umbrella header atomic.inline.hpp.
>> It removes includes of this header in files where it's not needed,
>> and adds it in all .cpp and .inline.hpp files where a method of
>> Atomic declared 'inline' is used.
>>
>> Also, the change moves some calls to such methods from .hpp files to
>> .inline.hpp files. In case of ASSERT code it moves the calls
>> to .cpp files.
>>
>> A row of headers still contain calls to inline methods of Atomic,
>> which I don't want to move as no appropriate .inline.hpp file is existing:
>>
>> src/share/vm/compiler/compileBroker.hpp
>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
>> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
>> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
>> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
>> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
>> src/share/vm/memory/specialized_oop_closures.hpp
>> src/share/vm/oops/methodData.hpp
>> src/share/vm/runtime/safepoint.hpp
>> src/share/vm/services/lowMemoryDetector.hpp
>> src/share/vm/services/memTracker.hpp
>> src/share/vm/utilities/taskqueue.hpp
>>
>> I compiled and tested this without precompiled headers on
>> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
>> in opt, dbg and fastdbg versions.
>>
>> Best regards,
>> Goetz.
From jesper.wilhelmsson at oracle.com Mon Jun 23 11:31:57 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Mon, 23 Jun 2014 13:31:57 +0200
Subject: RFR: 8047373: Clean the ExceptionCache in one pass
In-Reply-To: <53A2FDD8.5030501@oracle.com>
References: <53A2FDD8.5030501@oracle.com>
Message-ID: <53A8102D.5000900@oracle.com>
Looks good.
/Jesper
Stefan Karlsson skrev 19/6/14 17:12:
> Hi all,
>
> Please, review this patch to clean the ExceptionCache in one pass, instead of
> re-searching for the element to remove. The patch also makes
> nmethod::do_unloading little bit easier to read, IMHO.
>
> http://cr.openjdk.java.net/~stefank/8047373/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8047373
>
> This patch has been used and tested in the G1 Class Unloading project.
>
> thanks,
> StefanK
>
From erik.helin at oracle.com Mon Jun 23 12:18:30 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 23 Jun 2014 14:18:30 +0200
Subject: RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected
heap size on sparcv9
In-Reply-To: <536BA420.5000408@oracle.com>
References: <5368A0D6.5050609@oracle.com> <5368C396.4020206@oracle.com>
<536BA420.5000408@oracle.com>
Message-ID: <2820578.DKf8KbUPpN@ehelin-laptop>
Stefan, Jon,
I forgot to remove the "@ignore" line from the actual test,
TestParallelHeapSizeFlags.java. Please see new webrev at:
http://cr.openjdk.java.net/~ehelin/8027915/webrev.02/
and the very small (one line) incremental webrev at:
http://cr.openjdk.java.net/~ehelin/8027915/webrev.01-02/
Thanks,
Erik
On Thursday 08 May 2014 17:34:56 PM Erik Helin wrote:
> Hi Stefan,
>
> thanks for your thorough review! Please see new webrev at:
> http://cr.openjdk.java.net/~ehelin/8027915/webrev.01/
>
> and incremental webrev at:
> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00-01/
>
> and comments inline!
>
> On 2014-05-06 13:12, Stefan Johansson wrote:
> > Hi Erik,
> >
> > Thanks for making page_size_for_region more strict. A few comments:
> >
> > src/share/vm/runtime/os.cpp
> >
> > With this fix page_size_for_region doesn't care about alignment at all
> > (old version wasn't much better) and to me that feels wrong. I would
> > expect to get a page size that the given region sizes is aligned to, but
> > I might be missing some use case where that isn't needed.
>
> Agree, page_size_for_region should check alignment for large pages.
> Added fix and regression tests.
>
> On 2014-05-06 13:12, Stefan Johansson wrote:
> > src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
> >
> > For the heap we want both min and max to be a multiple of the page size
> > so we shoud call page_size_for_region for both _min_heap_byte_size and
> > _max_heap_byte_size and use the smallest of the two returned page sizes.
>
> Agree, fixed.
>
> On 2014-05-06 13:12, Stefan Johansson wrote:
> > src/share/vm/memory/heap.cpp
> >
> > The current patch will not change the default behavior so I'm fine with
> > just calling page_size_for_region once using reserved_size, but someone
> > with more insight might know if we should handle it the same way as the
> > generationSizer and use both committed and reserved.
>
> Since I'm not sure how the compiler guys want to handle this, I opted
> for the safe alternative and updated the patch to be backwards
> compatible with the old code (except slightly more strict).
>
> Thanks,
> Erik
>
> > Thanks,
> > Stefan
> >
> > On 2014-05-06 10:44, Erik Helin wrote:
> >> Hi all,
> >>
> >> this patch changes
> >> os::page_size_for_region(min_size, max_size, min_pages) to always
> >> guarantee that the returned page size <= max_size / min_pages. Prior
> >> to this patch, page_size_for_region could return a page size larger
> >> than max_size / min_pages. This can cause some unexpected behavior
> >> for code using page_size_for_region, such as the following regression
> >> tests:
> >>
> >> http://cr.openjdk.java.net/~ehelin/8027915/regression-test/
> >>
> >> As the test shows, if you have a 2 MB region and you must use at least
> >> 2 pages, you would still get back 2 MB as the page size on a Linux
> >> machine that supports 2 MB large pages. The reason for this is
> >> explained in a comment above the function in os.hpp:
> >>
> >> // The current implementation ignores min_pages if a larger page
> >> // size is an exact multiple of both region_min_size and
> >> // region_max_size. This allows larger pages to be used when doing
> >> // so would not cause fragmentation; in particular, a single page can
> >> // be used when region_min_size == region_max_size == a supported page
> >> // size.
> >>
> >> Reducing fragmentation of large pages is good but the varying return
> >> value makes it very hard to depend on os::page_size_for_region in
> >> calculations (for example when sizing the heap).
> >>
> >> This patch removes the fragmentation prevention mechanism, simplifies
> >> the function and adds a regression tests:
> >>
> >> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00/
> >>
> >> Testing:
> >> - JPRT
> >>
> >> Thanks,
> >> Erik
From stefan.karlsson at oracle.com Mon Jun 23 13:27:02 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 23 Jun 2014 15:27:02 +0200
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CED728D@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
<53902C7E.5010108@oracle.com>
<4295855A5C1DE049A61835A1887419CC2CEC706B@DEWDFEMB12A.global.corp.sap>
<5396BFF1.7080305@oracle.com>
<4295855A5C1DE049A61835A1887419CC2CED728D@DEWDFEMB12A.global.corp.sap>
Message-ID: <53A82B26.20508@oracle.com>
On 2014-06-23 11:54, Lindenmaier, Goetz wrote:
> Hi Stefan,
>
> thanks for the review!
>
> I still need a sponsor for this.
> Could you please push this change?
Sure. Your change has been pushed to hs-gc:
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b596a1063e90
Cheers,
StefanK
>
> Thanks,
> Goetz.
>
>
> -----Original Message-----
> From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
> Sent: Dienstag, 10. Juni 2014 10:21
> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
>
>
> On 2014-06-05 22:23, Lindenmaier, Goetz wrote:
>> Hi Stefan,
>>
>> thanks for the thorough review!
>>
>>> Thanks again for cleaning up the include files.
>> I checked the other includes, I would like to do this for os_<os>.inline.hpp, too.
>> That include cascade is shorter, but used in around 30 files.
>> Other more prominent cascades are
>> bytes_<cpu>.hpp (12 cascades),
>> ad_<cpu>.hpp (10 cascades),
>> nativeInst_<cpu>.hpp (8)
>> vmreg.inline_<cpu>.hpp (7)
>> As we have another 3 cpus (zArch, parisc, ia64), that would clean up our code
>> nicely ;)
>>
>> Back to this change:
>>
>> I moved the Atomics in StringDedup.hpp as you requested.
>> I removed the include in markSweep.inline.hpp.
>> I moved the include in oop.pcgc.inline.hpp up.
>> I moved the debug methods in gcLocker.hpp to the cpp file.
>>
>>> This is a lot of noise just to get rid of a call to the the
>>> CompiledICHolder constructor in product builds. Is it really worth it?
>> I think not. Moved to cpp file.
>>
>> About adding the header to precompiled.hpp: I don't really care,
>> I just follow the current pattern. As there were no other comments
>> on your request in the last change, I removed it this time.
>>
>> Here is the new webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.01
> Thanks.
>
> Looks good to me.
>
> StefanK
>
>> Best regards,
>> Goetz.
>>
>>
>> -----Original Message-----
>> From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
>> Sent: Donnerstag, 5. Juni 2014 10:38
>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
>>
>> Hi Goetz,
>>
>> Thanks again for cleaning up the include files.
>>
>> On 2014-06-04 15:59, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I would like to do another change cleaning up the includes of
>>> .inline.hpp files from the os_cpu directories.
>>>
>>> Please review and test this change. I please need a sponsor.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.hpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.cpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupQueue.cpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp.udiff.html
>>
>> I think it would be good to move the Atomic calls out from the
>> g1StringDedup.hpp to g1StringDedup.cpp. I talked to Per, the author of
>> StringDedup, and he would be fine with that move.
>> I moved the debug methods in gcLocker.hpp to the cpp file.
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.frames.html
>>
>> 32 #if INCLUDE_ALL_GCS
>> 33 #include "gc_implementation/g1/g1StringDedup.hpp"
>> 34 #include "gc_implementation/parallelScavenge/psParallelCompact.hpp"
>> 35 #include "runtime/atomic.inline.hpp"
>> 36 #endif // INCLUDE_ALL_GCS
>>
>> Why was this include added? Was it becuase g1StringDedup.hpp was added?
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/mutableSpace.cpp.frames.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/oop.pcgc.inline.hpp.frames.html
>>
>> 25 #include "precompiled.hpp"
>> 26 #include "utilities/macros.hpp"
>> 27 #if INCLUDE_ALL_GCS
>> 28 #include "gc_implementation/shared/mutableSpace.hpp"
>> 29 #include "gc_implementation/shared/spaceDecorator.hpp"
>> 30 #include "oops/oop.inline.hpp"
>> 31 #include "runtime/safepoint.hpp"
>> 32 #include "runtime/thread.hpp"
>> 33 #endif // INCLUDE_ALL_GCS
>> 34 #include "runtime/atomic.inline.hpp"
>>
>> Could you place the new includes together with the includes before the
>> INCLUDE_ALL_GCS block?
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.hpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.inline.hpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/runtime/safepoint.cpp.udiff.html
>>
>> + inline static void increment_debug_jni_lock_count();
>> + inline static void decrement_debug_jni_lock_count();
>>
>> This is debugging code, so it would be better to move it to the .cpp file.
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/compiledICHolder.hpp.udiff.html
>>
>> 54 #ifdef ASSERT
>> 55 CompiledICHolder(Method* method, Klass* klass);
>> 56 #else
>> 57 CompiledICHolder(Method* method, Klass* klass)
>> 58 : _holder_method(method), _holder_klass(klass) {};
>> 59 #endif
>> 60
>> 61 ~CompiledICHolder() NOT_DEBUG_RETURN;
>>
>> This is a lot of noise just to get rid of a call to the the
>> CompiledICHolder constructor in product builds. Is it really worth it?
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/precompiled/precompiled.hpp.udiff.html
>>
>> # include "runtime/atomic.hpp"
>> +# include "runtime/atomic.inline.hpp"
>>
>> I still think this is a bad idea. It will just make it more likely that
>> someone building with precompiled headers will forget to include
>> atomic.inline.hpp, and we would have to clean it up later when we found
>> out that it breaks some platform outside of Oracle's test matrix.
>>
>> thanks,
>> StefanK
>>
>>> This change improves the usage of the umbrella header atomic.inline.hpp.
>>> It removes includes of this header in files where it's not needed,
>>> and adds it in all .cpp and .inline.hpp files where a method of
>>> Atomic declared 'inline' is used.
>>>
>>> Also, the change moves some calls to such methods from .hpp files to
>>> .inline.hpp files. In case of ASSERT code it moves the calls
>>> to .cpp files.
>>>
>>> A row of headers still contain calls to inline methods of Atomic,
>>> which I don't want to move as no appropriate .inline.hpp file is existing:
>>>
>>> src/share/vm/compiler/compileBroker.hpp
>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
>>> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
>>> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
>>> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
>>> src/share/vm/memory/specialized_oop_closures.hpp
>>> src/share/vm/oops/methodData.hpp
>>> src/share/vm/runtime/safepoint.hpp
>>> src/share/vm/services/lowMemoryDetector.hpp
>>> src/share/vm/services/memTracker.hpp
>>> src/share/vm/utilities/taskqueue.hpp
>>>
>>> I compiled and tested this without precompiled headers on
>>> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
>>> in opt, dbg and fastdbg versions.
>>>
>>> Best regards,
>>> Goetz.
From goetz.lindenmaier at sap.com Mon Jun 23 14:06:38 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 23 Jun 2014 14:06:38 +0000
Subject: RFR(M): 8044775: Improve usage of umbrella header
atomic.inline.hpp.
In-Reply-To: <53A82B26.20508@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CEC6591@DEWDFEMB12A.global.corp.sap>
<53902C7E.5010108@oracle.com>
<4295855A5C1DE049A61835A1887419CC2CEC706B@DEWDFEMB12A.global.corp.sap>
<5396BFF1.7080305@oracle.com>
<4295855A5C1DE049A61835A1887419CC2CED728D@DEWDFEMB12A.global.corp.sap>
<53A82B26.20508@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CED734D@DEWDFEMB12A.global.corp.sap>
Thanks, that was fast!
Best regards,
Goetz
-----Original Message-----
From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
Sent: Montag, 23. Juni 2014 15:27
To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
On 2014-06-23 11:54, Lindenmaier, Goetz wrote:
> Hi Stefan,
>
> thanks for the review!
>
> I still need a sponsor for this.
> Could you please push this change?
Sure. Your change has been pushed to hs-gc:
http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b596a1063e90
Cheers,
StefanK
>
> Thanks,
> Goetz.
>
>
> -----Original Message-----
> From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
> Sent: Dienstag, 10. Juni 2014 10:21
> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
>
>
> On 2014-06-05 22:23, Lindenmaier, Goetz wrote:
>> Hi Stefan,
>>
>> thanks for the thorough review!
>>
>>> Thanks again for cleaning up the include files.
>> I checked the other includes, I would like to do this for os_<os>.inline.hpp, too.
>> That include cascade is shorter, but used in around 30 files.
>> Other more prominent cascades are
>> bytes_<cpu>.hpp (12 cascades),
>> ad_<cpu>.hpp (10 cascades),
>> nativeInst_<cpu>.hpp (8)
>> vmreg.inline_<cpu>.hpp (7)
>> As we have another 3 cpus (zArch, parisc, ia64), that would clean up our code
>> nicely ;)
>>
>> Back to this change:
>>
>> I moved the Atomics in StringDedup.hpp as you requested.
>> I removed the include in markSweep.inline.hpp.
>> I moved the include in oop.pcgc.inline.hpp up.
>> I moved the debug methods in gcLocker.hpp to the cpp file.
>>
>>> This is a lot of noise just to get rid of a call to the the
>>> CompiledICHolder constructor in product builds. Is it really worth it?
>> I think not. Moved to cpp file.
>>
>> About adding the header to precompiled.hpp: I don't really care,
>> I just follow the current pattern. As there were no other comments
>> on your request in the last change, I removed it this time.
>>
>> Here is the new webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.01
> Thanks.
>
> Looks good to me.
>
> StefanK
>
>> Best regards,
>> Goetz.
>>
>>
>> -----Original Message-----
>> From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com]
>> Sent: Donnerstag, 5. Juni 2014 10:38
>> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
>> Subject: Re: RFR(M): 8044775: Improve usage of umbrella header atomic.inline.hpp.
>>
>> Hi Goetz,
>>
>> Thanks again for cleaning up the include files.
>>
>> On 2014-06-04 15:59, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I would like to do another change cleaning up the includes of
>>> .inline.hpp files from the os_cpu directories.
>>>
>>> Please review and test this change. I please need a sponsor.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.hpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedup.cpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupQueue.cpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/g1/g1StringDedupThread.cpp.udiff.html
>>
>> I think it would be good to move the Atomic calls out from the
>> g1StringDedup.hpp to g1StringDedup.cpp. I talked to Per, the author of
>> StringDedup, and he would be fine with that move.
>> I moved the debug methods in gcLocker.hpp to the cpp file.
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/markSweep.inline.hpp.frames.html
>>
>> 32 #if INCLUDE_ALL_GCS
>> 33 #include "gc_implementation/g1/g1StringDedup.hpp"
>> 34 #include "gc_implementation/parallelScavenge/psParallelCompact.hpp"
>> 35 #include "runtime/atomic.inline.hpp"
>> 36 #endif // INCLUDE_ALL_GCS
>>
>> Why was this include added? Was it becuase g1StringDedup.hpp was added?
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/gc_implementation/shared/mutableSpace.cpp.frames.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/oop.pcgc.inline.hpp.frames.html
>>
>> 25 #include "precompiled.hpp"
>> 26 #include "utilities/macros.hpp"
>> 27 #if INCLUDE_ALL_GCS
>> 28 #include "gc_implementation/shared/mutableSpace.hpp"
>> 29 #include "gc_implementation/shared/spaceDecorator.hpp"
>> 30 #include "oops/oop.inline.hpp"
>> 31 #include "runtime/safepoint.hpp"
>> 32 #include "runtime/thread.hpp"
>> 33 #endif // INCLUDE_ALL_GCS
>> 34 #include "runtime/atomic.inline.hpp"
>>
>> Could you place the new includes together with the includes before the
>> INCLUDE_ALL_GCS block?
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.hpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/memory/gcLocker.inline.hpp.udiff.html
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/runtime/safepoint.cpp.udiff.html
>>
>> + inline static void increment_debug_jni_lock_count();
>> + inline static void decrement_debug_jni_lock_count();
>>
>> This is debugging code, so it would be better to move it to the .cpp file.
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/oops/compiledICHolder.hpp.udiff.html
>>
>> 54 #ifdef ASSERT
>> 55 CompiledICHolder(Method* method, Klass* klass);
>> 56 #else
>> 57 CompiledICHolder(Method* method, Klass* klass)
>> 58 : _holder_method(method), _holder_klass(klass) {};
>> 59 #endif
>> 60
>> 61 ~CompiledICHolder() NOT_DEBUG_RETURN;
>>
>> This is a lot of noise just to get rid of a call to the the
>> CompiledICHolder constructor in product builds. Is it really worth it?
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8044775-atomInc/webrev.00/src/share/vm/precompiled/precompiled.hpp.udiff.html
>>
>> # include "runtime/atomic.hpp"
>> +# include "runtime/atomic.inline.hpp"
>>
>> I still think this is a bad idea. It will just make it more likely that
>> someone building with precompiled headers will forget to include
>> atomic.inline.hpp, and we would have to clean it up later when we found
>> out that it breaks some platform outside of Oracle's test matrix.
>>
>> thanks,
>> StefanK
>>
>>> This change improves the usage of the umbrella header atomic.inline.hpp.
>>> It removes includes of this header in files where it's not needed,
>>> and adds it in all .cpp and .inline.hpp files where a method of
>>> Atomic declared 'inline' is used.
>>>
>>> Also, the change moves some calls to such methods from .hpp files to
>>> .inline.hpp files. In case of ASSERT code it moves the calls
>>> to .cpp files.
>>>
>>> A row of headers still contain calls to inline methods of Atomic,
>>> which I don't want to move as no appropriate .inline.hpp file is existing:
>>>
>>> src/share/vm/compiler/compileBroker.hpp
>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp
>>> src/share/vm/gc_implementation/g1/g1StringDedup.hpp
>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp
>>> src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
>>> src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp
>>> src/share/vm/memory/specialized_oop_closures.hpp
>>> src/share/vm/oops/methodData.hpp
>>> src/share/vm/runtime/safepoint.hpp
>>> src/share/vm/services/lowMemoryDetector.hpp
>>> src/share/vm/services/memTracker.hpp
>>> src/share/vm/utilities/taskqueue.hpp
>>>
>>> I compiled and tested this without precompiled headers on
>>> linuxx86_64, linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64, aixppc64
>>> in opt, dbg and fastdbg versions.
>>>
>>> Best regards,
>>> Goetz.
From stefan.karlsson at oracle.com Mon Jun 23 15:53:34 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 23 Jun 2014 17:53:34 +0200
Subject: RFR: 8047373: Clean the ExceptionCache in one pass
In-Reply-To: <E31B9B8E-08BC-4591-BF40-3EA4E609839E@oracle.com>
References: <53A2FDD8.5030501@oracle.com>
<E31B9B8E-08BC-4591-BF40-3EA4E609839E@oracle.com>
Message-ID: <53A84D7E.8070504@oracle.com>
On 2014-06-20 20:51, Kim Barrett wrote:
> Not sure my opinion counts for much yet, but this looks good to me.
Thanks for the review! The only problem is that you don't have an
OpenJDK name, so I can't put you on the Reviewed-by line.
thanks,
StefanK
>
> On Jun 19, 2014, at 11:12 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>> Hi all,
>>
>> Please, review this patch to clean the ExceptionCache in one pass, instead of re-searching for the element to remove. The patch also makes nmethod::do_unloading little bit easier to read, IMHO.
>>
>> http://cr.openjdk.java.net/~stefank/8047373/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8047373
>>
>> This patch has been used and tested in the G1 Class Unloading project.
>>
>> thanks,
>> StefanK
>
From stefan.karlsson at oracle.com Mon Jun 23 15:53:59 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 23 Jun 2014 17:53:59 +0200
Subject: RFR: 8047373: Clean the ExceptionCache in one pass
In-Reply-To: <53A4C55F.60906@oracle.com>
References: <53A2FDD8.5030501@oracle.com> <53A4C55F.60906@oracle.com>
Message-ID: <53A84D97.2020700@oracle.com>
On 2014-06-21 01:35, Jon Masamitsu wrote:
> Change looks good.
>
> Reviewed.
Thanks!
StefanK
>
> Jon
>
> On 6/19/2014 8:12 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this patch to clean the ExceptionCache in one pass,
>> instead of re-searching for the element to remove. The patch also
>> makes nmethod::do_unloading little bit easier to read, IMHO.
>>
>> http://cr.openjdk.java.net/~stefank/8047373/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8047373
>>
>> This patch has been used and tested in the G1 Class Unloading project.
>>
>> thanks,
>> StefanK
>>
>
From stefan.karlsson at oracle.com Mon Jun 23 15:54:14 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 23 Jun 2014 17:54:14 +0200
Subject: RFR: 8047373: Clean the ExceptionCache in one pass
In-Reply-To: <53A8102D.5000900@oracle.com>
References: <53A2FDD8.5030501@oracle.com> <53A8102D.5000900@oracle.com>
Message-ID: <53A84DA6.1010701@oracle.com>
On 2014-06-23 13:31, Jesper Wilhelmsson wrote:
> Looks good.
Thanks!
StefanK
> /Jesper
>
> Stefan Karlsson skrev 19/6/14 17:12:
>> Hi all,
>>
>> Please, review this patch to clean the ExceptionCache in one pass,
>> instead of
>> re-searching for the element to remove. The patch also makes
>> nmethod::do_unloading little bit easier to read, IMHO.
>>
>> http://cr.openjdk.java.net/~stefank/8047373/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8047373
>>
>> This patch has been used and tested in the G1 Class Unloading project.
>>
>> thanks,
>> StefanK
>>
From volker.simonis at gmail.com Mon Jun 23 16:42:29 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 23 Jun 2014 18:42:29 +0200
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <53A092D4.3060100@oracle.com>
References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com>
<5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com>
<539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com>
<539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com>
Message-ID: <CA+3eh1102Wp_YW4sKoOaauwLo0OaNx-q=Oqw=DA66WXG9GQ=ew@mail.gmail.com>
Hi Mikael,
sorry for the delayed answer - the PPC/AIX team was on holiday:)
I've tested your changes on AIX and Linux/PPC64. On AIX everything works fine.
For Linux/PPC64 there's a single occurrence of a test against $ARCH
which you've missed:
diff -r 116e9b1bf477 make/linux/Makefile
--- a/make/linux/Makefile Mon Jun 23 17:43:30 2014 +0200
+++ b/make/linux/Makefile Mon Jun 23 18:15:20 2014 +0200
@@ -67,8 +67,10 @@
endif
endif
# C1 is not ported on ppc64, so we cannot build a tiered VM:
-ifeq ($(ARCH),ppc64)
- FORCE_TIERED=0
+ifeq ($(ARCH),ppc)
+ ifeq ($(ARCH_DATA_MODEL), 64)
+ FORCE_TIERED=0
+ endif
endif
ifdef LP64
With this change I could successfully build on AIX and Linux/PPC64
(I've only tested complete builds).
Thank you and best regards,
Volker
On Tue, Jun 17, 2014 at 9:11 PM, Mikael Vidstedt
<mikael.vidstedt at oracle.com> wrote:
>
> New webrev here (only the hotspot part, the webrev for top hasn't changed):
>
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/
>
> Comments inline.
>
>
> On 2014-06-16 19:49, David Holmes wrote:
>>
>> Hi Mikael,
>>
>> Sorry for the delay ...
>>
>> make/aix/makefiles/defs.make:
>>
>> This change doesn't make sense to me:
>>
>> 48 ifneq (,$(findstring $(ARCH), ppc))
>>
>> given that the logic immediately preceding this sets ARCH to either ppc or
>> ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for both
>> 32-bit and 64-bit cross-builds but the earlier logic is really precluding
>> this. So it seems to me that the changes in this file are completely
>> unnecessary (or else the earlier logic also needs changing).
>
>
> Indeed, that is correct - I missed the fact that ARCH is always overriden to
> be either ppc or ppc64. The old logic is unnecessarily hard to follow, but I
> guess that's in line with our hotspot Makefiles in general ;)
>
> I'll revert the changes to the file and add a mental note to self and others
> that linux appears to be the only platform where the incoming value of ARCH
> is actually honored - it's ignored/overridden on Solaris, BSD and AIX.
>
>
>> make/linux/makefiles/defs.make
>>
>> This block:
>>
>> 86 # i686/i586 and amd64/x86_64
>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
>> 88 ifeq ($(ARCH_DATA_MODEL), 64)
>> 89 ARCH_DATA_MODEL = 64
>> 90 MAKE_ARGS += LP64=1
>> 91 PLATFORM = linux-amd64
>> 92 VM_PLATFORM = linux_amd64
>> 93 HS_ARCH = x86
>> 94 else
>> 95 ARCH_DATA_MODEL = 32
>> 96 PLATFORM = linux-i586
>> 97 VM_PLATFORM = linux_i486
>> 98 HS_ARCH = x86
>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it
>> 100 ARCH = i686
>> 101 endif
>> 102 endif
>>
>> seems to allow the user to try and do a 64-bit build on a 32-bit build
>> machine. Not sure if that would get caught in an earlier sanity check? (Same
>> is true for the sparc block).
>
>
> While the changes are primarily just intended to cut down on the duplication
> I don't immediately see the reason why we wouldn't want to allow compiling a
> 64-bit VM from a 32-bit machine? We're cross compiling all sorts of
> platforms, so why not allow this if the compiler supports it? I'd prefer to
> keep it this way.
>
>
>> Also I don't think the following is actually true:
>>
>> # We have to reset ARCH to i686 since SRCARCH relies on it
>> ARCH = i686
>>
>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture
>> designator will simply map to a SRCARCH of x86, as per defs.make:
>>
>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc
>> zero,$(ARCH)))
>> ARCH/ = x86
>> ARCH/sparc = sparc
>> ARCH/sparc64= sparc
>> ARCH/ia64 = ia64
>> ARCH/amd64 = x86
>> ARCH/x86_64 = x86
>> ARCH/ppc64 = ppc
>> ARCH/ppc = ppc
>> ARCH/arm = arm
>> ARCH/zero = zero
>
>
> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, ppc64,
> ppc, arm, zero } it will map to x86 anyway. I thought about cleaning that up
> before I sent out the first webrev, but soon found myself doing way more
> cleanup than was healthy for this specific change. However, since I had to
> update this change anyway I removed the ARCH reset part.
>
> Cheers,
> Mikael
>
>
>>
>>
>> Cheers,
>> David
>>
>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>>>
>>>
>>> Thanks Erik. Another review please?
>>>
>>> Cheers,
>>> Mikael
>>>
>>> On 2014-06-12 23:56, Erik Joelsson wrote:
>>>>
>>>> Looks fine to me.
>>>>
>>>> /Erik
>>>>
>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>>>
>>>>>
>>>>> I have now verified that the changes work just fine for the platforms
>>>>> we build and test - both from the top level and when building hotspot
>>>>> only. Taking suggestions on other tests to perform. And it would be
>>>>> great if somebody could test the changes on on aix/ppc.
>>>>>
>>>>> So, kindly asking for "real"/final reviews of the changes:
>>>>>
>>>>> top:
>>>>>
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>> hotspot:
>>>>>
>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>>>
>>>>>>
>>>>>> David,
>>>>>>
>>>>>> Thanks for the feedback. Essentially the logic in the
>>>>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>>>>> two different use cases:
>>>>>>
>>>>>> 1. ARCH being set by the JDK build system to the value of
>>>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>>>> typically from uname
>>>>>>
>>>>>> Since Solaris and bsd both override ARCH they do not care about
>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>>>
>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>>>> the hope that somebody can help out with that.
>>>>>>
>>>>>>
>>>>>> Summing it up, I have the following two webrevs:
>>>>>>
>>>>>> top:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>
>>>>>> hotspot:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>
>>>>>>
>>>>>> With these changes I can build the normal platforms, but more
>>>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>>>> feedback is much appreciated!
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>>>>
>>>>>>> Hi Mikael,
>>>>>>>
>>>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>>>
>>>>>>> As you note the main flow-on effect here is that the hotspot
>>>>>>> makefiles have to be updated for the cases where
>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>>>> only x86 has that issue.
>>>>>>>
>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>>>> both internally and in the build artifacts and bundles!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I need some feedback and comments on the below fix:
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>>>
>>>>>>>> Background:
>>>>>>>>
>>>>>>>> When configuring the hotspot build the build system sets up the ARCH
>>>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>>>> initialized
>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>>>> name. For
>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>>>>> The
>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>>>> gradually removed in favor of the other variables.
>>>>>>>>
>>>>>>>> Discussion:
>>>>>>>>
>>>>>>>> The two candidate variables to base ARCH on are as far as I can tell
>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single,
>>>>>>>> well
>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }.
>>>>>>>> Together
>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>>>> ignored on
>>>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>>>
>>>>>>>> Before I go too far with this though I'd like to get some feedback
>>>>>>>> on
>>>>>>>> whether or not this is the right approach and what the exact value
>>>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>>>> system may
>>>>>>>> have to be updated for some platforms to support the new value(s).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikael
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
From alejandro.murillo at oracle.com Mon Jun 23 18:54:38 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Mon, 23 Jun 2014 12:54:38 -0600
Subject: RFR 8043541: 'fastdebug' is printed twice in java -version
In-Reply-To: <53A4DB5D.3010303@oracle.com>
References: <53A2779A.70201@oracle.com> <53A4DB5D.3010303@oracle.com>
Message-ID: <53A877EE.9040501@oracle.com>
On 6/20/2014 7:09 PM, Daniel D. Daugherty wrote:
>
> On 6/18/14 11:39 PM, Alejandro E Murillo wrote:
>> Can I get a review for this change?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
>> webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
>
> make/aix/makefiles/vm.make
> No comments.
>
> make/bsd/makefiles/vm.make
> No comments.
>
> make/defs.make
> No comments.
>
> make/linux/makefiles/vm.make
> No comments.
>
> make/solaris/makefiles/vm.make
> No comments.
>
> make/windows/projectfiles/common/Makefile
> No comments.
>
> src/share/vm/runtime/vm_version.cpp
> It took me several readings to figure out what you're doing
> here. I'm not sure what my brain was doing wrong or how to
> clear it up for anyone else.
Thanks Dan,
I should have added a note explaining that change in the request.
I tried to add to the logic that was already there, and minimize the
changes,
David suggestion might make it easier to understand
Thanks
Alejandro
>
> Thumbs up.
>
>
> Dan
>
>
>>
>> Note that this was discovered through nightly testing, but is not per
>> se causing
>> any failures. It only affects full non product JDK builds. It does
>> not affect hotspot
>> only builds.
>>
>> The bug was initially filed as confidential, it's a p4, if you can't
>> see the description, here it is:
>> "After the format of the hotspot version string was changed now
>> 'fastdebug' is showing twice
>> in the hotspot version output of 'java -version' ONLY on Full non
>> product JDK builds as shown below:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
>> Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
>> mixed mode)
>> -----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^
>>
>>
>> Background about the fix:
>> In a nutshell, with this fix, the build target is added to
>> HOTSPOT_RELEASE_VERSION,
>> on hotspot/make/defs.make, and on Hotspot ONLY builds, instead of
>> passing it to
>> vm_version.cpp through HOTSPOT_TARGET_BUILD.
>>
>> HOWEVER, given the way the project to build hotspot (only) with
>> Visual Studio is created,
>> it is not possible to add that (HOTSPOT_TARGET_BUILD) to
>> HOTSPOT_RELEASE_VERSION
>> when the VS project is created, so HOTSPOT_TARGET_BUILD is still
>> passed to vm_version.cpp,
>> on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
>> building
>> with Visual studio. Building windows with gnu make (as jprt does)
>> will work as in other platforms.
>>
>> I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to
>> vm_version.cpp altogether, but I suspect it
>> was done that way to append the target build on non product builds
>> when using Visual studio.
>> If someone is familiar with the VS create.bat script and visual
>> studio in general, please
>> take a look and see if there's a way to pass that info at project
>> creation time, so that
>> we can completely get rid of passing HOTSPOT_TARGET_BUILD to
>> vm_version.cpp.
>> Please file an RFE if necessary.
>>
>> With this solution:
>> (a) For FULL JDK builds, 'fastdebug' will not be duplicated (bug
>> being fixed) on those builds.
>> (b) And for JUST hotspot only, non product builds, the output format
>> for the hotspot
>> version will slightly change from (see ^^^^^^ below):
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug,
>> mixed mode)
>> ------------------------------------------------------------------------------------------^^^^^^^^^
>>
>>
>> TO:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB,
>> mixed mode)
>> ----------------------------------------^^^^^^^^^----------------------------------------------------
>>
>>
>>
>> Basically 'fastdebug' is now added right after the jdk version,
>> before 'internal',
>> in the hotspot portion, instead of at the end. Product builds are
>> not affected at all.
>> note, those are outputs from hs only JPRT builds. Non JPRT hs only
>> builds may not have
>> anything after 'internal' (by default).
>>
>> thanks
>>
>
--
Alejandro
From alejandro.murillo at oracle.com Mon Jun 23 18:55:53 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Mon, 23 Jun 2014 12:55:53 -0600
Subject: RFR 8043541: 'fastdebug' is printed twice in java -version
In-Reply-To: <53A524C7.4010801@oracle.com>
References: <53A2779A.70201@oracle.com> <53A4DB5D.3010303@oracle.com>
<53A524C7.4010801@oracle.com>
Message-ID: <53A87839.8050104@oracle.com>
On 6/21/2014 12:23 AM, David Holmes wrote:
> On 21/06/2014 11:09 AM, Daniel D. Daugherty wrote:
>>
>> On 6/18/14 11:39 PM, Alejandro E Murillo wrote:
>>> Can I get a review for this change?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
>>> webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
>>
>> make/aix/makefiles/vm.make
>> No comments.
>>
>> make/bsd/makefiles/vm.make
>> No comments.
>>
>> make/defs.make
>> No comments.
>>
>> make/linux/makefiles/vm.make
>> No comments.
>>
>> make/solaris/makefiles/vm.make
>> No comments.
>>
>> make/windows/projectfiles/common/Makefile
>> No comments.
>>
>> src/share/vm/runtime/vm_version.cpp
>> It took me several readings to figure out what you're doing
>> here. I'm not sure what my brain was doing wrong or how to
>> clear it up for anyone else.
>
> I had the same issue. Inverting the logic might be clearer:
>
> if VS and not product
> do special stuff
> else
> do normal stuff
>
> but I'll leave it to Alejandro as to whether it is worth the effort to
> change.
yes, inverting the "if" can make it easier to understand it,
for the sake of clarity I will change it to this.
Thanks!
Alejandro
>
> David
>
>> Thumbs up.
>>
>>
>> Dan
>>
>>
>>>
>>> Note that this was discovered through nightly testing, but is not per
>>> se causing
>>> any failures. It only affects full non product JDK builds. It does not
>>> affect hotspot
>>> only builds.
>>>
>>> The bug was initially filed as confidential, it's a p4, if you can't
>>> see the description, here it is:
>>> "After the format of the hotspot version string was changed now
>>> 'fastdebug' is showing twice
>>> in the hotspot version output of 'java -version' ONLY on Full non
>>> product JDK builds as shown below:
>>>
>>> java version "1.9.0-ea-fastdebug"
>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
>>> Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
>>> mixed mode)
>>> -----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^
>>>
>>>
>>>
>>> Background about the fix:
>>> In a nutshell, with this fix, the build target is added to
>>> HOTSPOT_RELEASE_VERSION,
>>> on hotspot/make/defs.make, and on Hotspot ONLY builds, instead of
>>> passing it to
>>> vm_version.cpp through HOTSPOT_TARGET_BUILD.
>>>
>>> HOWEVER, given the way the project to build hotspot (only) with Visual
>>> Studio is created,
>>> it is not possible to add that (HOTSPOT_TARGET_BUILD) to
>>> HOTSPOT_RELEASE_VERSION
>>> when the VS project is created, so HOTSPOT_TARGET_BUILD is still
>>> passed to vm_version.cpp,
>>> on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
>>> building
>>> with Visual studio. Building windows with gnu make (as jprt does) will
>>> work as in other platforms.
>>>
>>> I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to
>>> vm_version.cpp altogether, but I suspect it
>>> was done that way to append the target build on non product builds
>>> when using Visual studio.
>>> If someone is familiar with the VS create.bat script and visual studio
>>> in general, please
>>> take a look and see if there's a way to pass that info at project
>>> creation time, so that
>>> we can completely get rid of passing HOTSPOT_TARGET_BUILD to
>>> vm_version.cpp.
>>> Please file an RFE if necessary.
>>>
>>> With this solution:
>>> (a) For FULL JDK builds, 'fastdebug' will not be duplicated (bug
>>> being fixed) on those builds.
>>> (b) And for JUST hotspot only, non product builds, the output format
>>> for the hotspot
>>> version will slightly change from (see ^^^^^^ below):
>>>
>>> java version "1.9.0-ea-fastdebug"
>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
>>> Java HotSpot(TM) Server VM (build
>>> 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug,
>>> mixed mode)
>>> ------------------------------------------------------------------------------------------^^^^^^^^^
>>>
>>>
>>>
>>> TO:
>>>
>>> java version "1.9.0-ea-fastdebug"
>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
>>> Java HotSpot(TM) Server VM (build
>>> 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB,
>>> mixed mode)
>>> ----------------------------------------^^^^^^^^^----------------------------------------------------
>>>
>>>
>>>
>>>
>>> Basically 'fastdebug' is now added right after the jdk version, before
>>> 'internal',
>>> in the hotspot portion, instead of at the end. Product builds are not
>>> affected at all.
>>> note, those are outputs from hs only JPRT builds. Non JPRT hs only
>>> builds may not have
>>> anything after 'internal' (by default).
>>>
>>> thanks
>>>
>>
--
Alejandro
From coleen.phillimore at oracle.com Mon Jun 23 23:45:44 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 23 Jun 2014 19:45:44 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A3A402.2060501@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
<53A3A402.2060501@oracle.com>
Message-ID: <53A8BC28.6030008@oracle.com>
Please review a change to the JDK code for adding classLoader field to
the instances of java/lang/Class. This change restricts reflection from
changing access to the classLoader field. In the spec,
AccessibleObject.setAccessible() may throw SecurityException if the
accessibility of an object may not be changed:
http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
Only AccessibleObject.java has changes from the previous version of this
change.
open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
bug link https://bugs.openjdk.java.net/browse/JDK-6642881
Thanks,
Coleen
On 6/19/14, 11:01 PM, David Holmes wrote:
> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>> Hi Mandy,
>>
>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>
>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>> Hi,
>>>>
>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>> <coleen.phillimore at oracle.com> wrote:
>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>> go away in 9 but ?).
>>>>> I don't know how to hide the field from reflection. It's a
>>>>> private final field so you need to get priviledges to make it
>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>> reason for this change is so that the JIT compilers can inline
>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>
>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>> a field from being found using reflection. It might very well be
>>>> the case that private and final is enough, I haven?t thought this
>>>> through 100%. On the other hand, is there a reason to give users
>>>> access through the field instead of having to use
>>>> Class.getClassLoader()?
>>>>
>>> There are many getter methods that returns a private final field.
>>> I'm not sure if hiding the field is necessary nor a good precedence
>>> to set. Accessing a private field requires "accessDeclaredMember"
>>> permission although it's a different security check (vs
>>> "getClassLoader"
>>> permission). Arguably before this new classLoader field, one could
>>> call Class.getClassLoader0() via reflection to get a hold of class
>>> loader.
>>>
>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>> is too coarse-grained? I think the security team is looking into
>>> the improvement in that regards.
>>
>> I think I?m a bit worried about two things, first as you wrote,
>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>> you could get the class loader through getClassLoader0() that
>> shouldn?t be a new issue.
>>
>> The second thing is that IIRC there are ways to set a final field
>> after initialization. I?m not sure we need to care about that either
>> if you need Unsafe to do it.
>
> Normal reflection can set a final field if you can successfully call
> setAccessible(true) on the Field object.
>
> David
> -----
>
>
>> cheers
>> /Joel
>>
From mikael.vidstedt at oracle.com Mon Jun 23 23:56:39 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 23 Jun 2014 16:56:39 -0700
Subject: RFR(M): 8047740: Add hotspot testset to jprt.properties
Message-ID: <53A8BEB7.6080300@oracle.com>
All,
Please review the below change which adds a "hotspot" testset to the top
level jprt.properties and makes it possible to do the equivalent of a
hotspot push job but from the top level -- building the whole/full JDK
but running the same old tests. The change should not change any
existing use cases, so unless using the hotspot testset specifically
everything should work exactly as it does today.
Bug: https://bugs.openjdk.java.net/browse/JDK-8047740
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8047740/webrev.00/webrev/
Note that the name of the testset is used to control not only which
platforms are being built and tested, but also whether a mercurial sync
should be made after build/before push - specifically, the testset is
"hotspot" handled differently from the other testsets.
I have manually verified that when running with the various testsets the
build and test target sets are the same as before the patch.
Thanks,
Mikael
From mandy.chung at oracle.com Tue Jun 24 01:36:57 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Jun 2014 18:36:57 -0700
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
<53A3A402.2060501@oracle.com> <53A8BC28.6030008@oracle.com>
Message-ID: <53A8D639.8030605@oracle.com>
Coleen,
On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to
> the instances of java/lang/Class. This change restricts reflection
> from changing access to the classLoader field. In the spec,
> AccessibleObject.setAccessible() may throw SecurityException if the
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>
>
> Only AccessibleObject.java has changes from the previous version of
> this change.
>
This change looks reasonable. As a side note: Joel mentions about
the mechanism to hide class members from reflection. I discussed with
Joel offline before he went on parental leave and suggest that we should
revisit the two mechanisms that both effectively disallow access to
private members in the future.
Mandy
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Thanks,
> Coleen
>
> On 6/19/14, 11:01 PM, David Holmes wrote:
>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>> Hi Mandy,
>>>
>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>
>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>> Hi,
>>>>>
>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>> should go away in 9 but ?).
>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>> private final field so you need to get priviledges to make it
>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>>
>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>> hides a field from being found using reflection. It might very
>>>>> well be the case that private and final is enough, I haven?t
>>>>> thought this through 100%. On the other hand, is there a reason to
>>>>> give users access through the field instead of having to use
>>>>> Class.getClassLoader()?
>>>>>
>>>> There are many getter methods that returns a private final field.
>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>> permission although it's a different security check (vs
>>>> "getClassLoader"
>>>> permission). Arguably before this new classLoader field, one could
>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>> loader.
>>>>
>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>> is too coarse-grained? I think the security team is looking into
>>>> the improvement in that regards.
>>>
>>> I think I?m a bit worried about two things, first as you wrote,
>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>> you could get the class loader through getClassLoader0() that
>>> shouldn?t be a new issue.
>>>
>>> The second thing is that IIRC there are ways to set a final field
>>> after initialization. I?m not sure we need to care about that either
>>> if you need Unsafe to do it.
>>
>> Normal reflection can set a final field if you can successfully call
>> setAccessible(true) on the Field object.
>>
>> David
>> -----
>>
>>
>>> cheers
>>> /Joel
>>>
>
From coleen.phillimore at oracle.com Tue Jun 24 01:44:53 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 23 Jun 2014 21:44:53 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8D639.8030605@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
<53A3A402.2060501@oracle.com> <53A8BC28.6030008@oracle.com>
<53A8D639.8030605@oracle.com>
Message-ID: <53A8D815.8000901@oracle.com>
On 6/23/14, 9:36 PM, Mandy Chung wrote:
> Coleen,
>
> On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field
>> to the instances of java/lang/Class. This change restricts
>> reflection from changing access to the classLoader field. In the
>> spec, AccessibleObject.setAccessible() may throw SecurityException if
>> the accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>
>>
>> Only AccessibleObject.java has changes from the previous version of
>> this change.
>>
>
> This change looks reasonable. As a side note: Joel mentions about
> the mechanism to hide class members from reflection. I discussed
> with Joel offline before he went on parental leave and suggest that we
> should revisit the two mechanisms that both effectively disallow
> access to private members in the future.
Thanks, Mandy. Yes, let me know what you come up with and we can
improve this. Thank you for the help fixing this bug.
Coleen
>
> Mandy
>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>>> should go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>> private final field so you need to get priviledges to make it
>>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>>> hides a field from being found using reflection. It might very
>>>>>> well be the case that private and final is enough, I haven?t
>>>>>> thought this through 100%. On the other hand, is there a reason
>>>>>> to give users access through the field instead of having to use
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs
>>>>> "getClassLoader"
>>>>> permission). Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained? I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote,
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but
>>>> since you could get the class loader through getClassLoader0() that
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field
>>>> after initialization. I?m not sure we need to care about that
>>>> either if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>
From david.holmes at oracle.com Tue Jun 24 02:11:51 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jun 2014 12:11:51 +1000
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8D815.8000901@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com>
<53A3A402.2060501@oracle.com> <53A8BC28.6030008@oracle.com>
<53A8D639.8030605@oracle.com> <53A8D815.8000901@oracle.com>
Message-ID: <53A8DE67.60808@oracle.com>
On 24/06/2014 11:44 AM, Coleen Phillimore wrote:
>
> On 6/23/14, 9:36 PM, Mandy Chung wrote:
>> Coleen,
>>
>> On 6/23/2014 4:45 PM, Coleen Phillimore wrote:
>>>
>>> Please review a change to the JDK code for adding classLoader field
>>> to the instances of java/lang/Class. This change restricts
>>> reflection from changing access to the classLoader field. In the
>>> spec, AccessibleObject.setAccessible() may throw SecurityException if
>>> the accessibility of an object may not be changed:
>>>
>>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>>
>>>
>>> Only AccessibleObject.java has changes from the previous version of
>>> this change.
>>>
>>
>> This change looks reasonable. As a side note: Joel mentions about
>> the mechanism to hide class members from reflection. I discussed
>> with Joel offline before he went on parental leave and suggest that we
>> should revisit the two mechanisms that both effectively disallow
>> access to private members in the future.
>
> Thanks, Mandy. Yes, let me know what you come up with and we can
> improve this. Thank you for the help fixing this bug.
Note that completely hiding something from reflection is different to
controlling its accessability via reflection. I think what is being done
here is the right way to go.
The changes look okay to me.
Thanks,
David
> Coleen
>
>>
>> Mandy
>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>>> Hi Mandy,
>>>>>
>>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>>
>>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>>>> should go away in 9 but ?).
>>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>>> private final field so you need to get priviledges to make it
>>>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>>> loader.
>>>>>>>>
>>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>>>> hides a field from being found using reflection. It might very
>>>>>>> well be the case that private and final is enough, I haven?t
>>>>>>> thought this through 100%. On the other hand, is there a reason
>>>>>>> to give users access through the field instead of having to use
>>>>>>> Class.getClassLoader()?
>>>>>>>
>>>>>> There are many getter methods that returns a private final field.
>>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>>> permission although it's a different security check (vs
>>>>>> "getClassLoader"
>>>>>> permission). Arguably before this new classLoader field, one could
>>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>>> loader.
>>>>>>
>>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>>> is too coarse-grained? I think the security team is looking into
>>>>>> the improvement in that regards.
>>>>>
>>>>> I think I?m a bit worried about two things, first as you wrote,
>>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but
>>>>> since you could get the class loader through getClassLoader0() that
>>>>> shouldn?t be a new issue.
>>>>>
>>>>> The second thing is that IIRC there are ways to set a final field
>>>>> after initialization. I?m not sure we need to care about that
>>>>> either if you need Unsafe to do it.
>>>>
>>>> Normal reflection can set a final field if you can successfully call
>>>> setAccessible(true) on the Field object.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> cheers
>>>>> /Joel
>>>>>
>>>
>>
>
From Alan.Bateman at oracle.com Tue Jun 24 07:13:29 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Jun 2014 08:13:29 +0100
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> <53A3A402.2060501@oracle.com>
<53A8BC28.6030008@oracle.com>
Message-ID: <53A92519.6010407@oracle.com>
On 24/06/2014 00:45, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to
> the instances of java/lang/Class. This change restricts reflection
> from changing access to the classLoader field. In the spec,
> AccessibleObject.setAccessible() may throw SecurityException if the
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>
>
> Only AccessibleObject.java has changes from the previous version of
> this change.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
Having setAccessible throw SecurityException when there isn't a security
manager set is a bit odd but as you point out, setAccessible is
specified to allow that. The changes looks okay, although I don't think
strictly necessary.
-Alan.
From david.holmes at oracle.com Tue Jun 24 07:35:06 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jun 2014 17:35:06 +1000
Subject: RFR(M): 8047740: Add hotspot testset to jprt.properties
In-Reply-To: <53A8BEB7.6080300@oracle.com>
References: <53A8BEB7.6080300@oracle.com>
Message-ID: <53A92A2A.2020907@oracle.com>
Looks good to me!
Thanks,
David
On 24/06/2014 9:56 AM, Mikael Vidstedt wrote:
>
> All,
>
> Please review the below change which adds a "hotspot" testset to the top
> level jprt.properties and makes it possible to do the equivalent of a
> hotspot push job but from the top level -- building the whole/full JDK
> but running the same old tests. The change should not change any
> existing use cases, so unless using the hotspot testset specifically
> everything should work exactly as it does today.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8047740
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8047740/webrev.00/webrev/
>
> Note that the name of the testset is used to control not only which
> platforms are being built and tested, but also whether a mercurial sync
> should be made after build/before push - specifically, the testset is
> "hotspot" handled differently from the other testsets.
>
> I have manually verified that when running with the various testsets the
> build and test target sets are the same as before the patch.
>
> Thanks,
> Mikael
>
From stefan.johansson at oracle.com Tue Jun 24 07:57:52 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 24 Jun 2014 09:57:52 +0200
Subject: RFR: 8027915: TestParallelHeapSizeFlags fails with unexpected
heap size on sparcv9
In-Reply-To: <2820578.DKf8KbUPpN@ehelin-laptop>
References: <5368A0D6.5050609@oracle.com> <5368C396.4020206@oracle.com>
<536BA420.5000408@oracle.com> <2820578.DKf8KbUPpN@ehelin-laptop>
Message-ID: <53A92F80.7020103@oracle.com>
On 2014-06-23 14:18, Erik Helin wrote:
> Stefan, Jon,
>
> I forgot to remove the "@ignore" line from the actual test,
> TestParallelHeapSizeFlags.java. Please see new webrev at:
> http://cr.openjdk.java.net/~ehelin/8027915/webrev.02/
>
> and the very small (one line) incremental webrev at:
> http://cr.openjdk.java.net/~ehelin/8027915/webrev.01-02/
Good catch, ship it!
StefanJ
>
> Thanks,
> Erik
>
> On Thursday 08 May 2014 17:34:56 PM Erik Helin wrote:
>> Hi Stefan,
>>
>> thanks for your thorough review! Please see new webrev at:
>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.01/
>>
>> and incremental webrev at:
>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00-01/
>>
>> and comments inline!
>>
>> On 2014-05-06 13:12, Stefan Johansson wrote:
>>> Hi Erik,
>>>
>>> Thanks for making page_size_for_region more strict. A few comments:
>>>
>>> src/share/vm/runtime/os.cpp
>>>
>>> With this fix page_size_for_region doesn't care about alignment at all
>>> (old version wasn't much better) and to me that feels wrong. I would
>>> expect to get a page size that the given region sizes is aligned to, but
>>> I might be missing some use case where that isn't needed.
>> Agree, page_size_for_region should check alignment for large pages.
>> Added fix and regression tests.
>>
>> On 2014-05-06 13:12, Stefan Johansson wrote:
>>> src/share/vm/gc_implementation/parallelScavenge/generationSizer.cpp
>>>
>>> For the heap we want both min and max to be a multiple of the page size
>>> so we shoud call page_size_for_region for both _min_heap_byte_size and
>>> _max_heap_byte_size and use the smallest of the two returned page sizes.
>> Agree, fixed.
>>
>> On 2014-05-06 13:12, Stefan Johansson wrote:
>>> src/share/vm/memory/heap.cpp
>>>
>>> The current patch will not change the default behavior so I'm fine with
>>> just calling page_size_for_region once using reserved_size, but someone
>>> with more insight might know if we should handle it the same way as the
>>> generationSizer and use both committed and reserved.
>> Since I'm not sure how the compiler guys want to handle this, I opted
>> for the safe alternative and updated the patch to be backwards
>> compatible with the old code (except slightly more strict).
>>
>> Thanks,
>> Erik
>>
>>> Thanks,
>>> Stefan
>>>
>>> On 2014-05-06 10:44, Erik Helin wrote:
>>>> Hi all,
>>>>
>>>> this patch changes
>>>> os::page_size_for_region(min_size, max_size, min_pages) to always
>>>> guarantee that the returned page size <= max_size / min_pages. Prior
>>>> to this patch, page_size_for_region could return a page size larger
>>>> than max_size / min_pages. This can cause some unexpected behavior
>>>> for code using page_size_for_region, such as the following regression
>>>> tests:
>>>>
>>>> http://cr.openjdk.java.net/~ehelin/8027915/regression-test/
>>>>
>>>> As the test shows, if you have a 2 MB region and you must use at least
>>>> 2 pages, you would still get back 2 MB as the page size on a Linux
>>>> machine that supports 2 MB large pages. The reason for this is
>>>> explained in a comment above the function in os.hpp:
>>>>
>>>> // The current implementation ignores min_pages if a larger page
>>>> // size is an exact multiple of both region_min_size and
>>>> // region_max_size. This allows larger pages to be used when doing
>>>> // so would not cause fragmentation; in particular, a single page can
>>>> // be used when region_min_size == region_max_size == a supported page
>>>> // size.
>>>>
>>>> Reducing fragmentation of large pages is good but the varying return
>>>> value makes it very hard to depend on os::page_size_for_region in
>>>> calculations (for example when sizing the heap).
>>>>
>>>> This patch removes the fragmentation prevention mechanism, simplifies
>>>> the function and adds a regression tests:
>>>>
>>>> http://cr.openjdk.java.net/~ehelin/8027915/webrev.00/
>>>>
>>>> Testing:
>>>> - JPRT
>>>>
>>>> Thanks,
>>>> Erik
From frederic.parain at oracle.com Tue Jun 24 08:41:40 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 24 Jun 2014 10:41:40 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> <53A3A402.2060501@oracle.com>
<53A8BC28.6030008@oracle.com>
Message-ID: <53A939C4.2080703@oracle.com>
Hi Coleen,
It seems that there's still a reference to JVM_GetClassLoader
in file jdk/src/share/native/common/check_code.c. The code looks
like dead code, but it would be nice to clean it up.
Thanks,
Fred
On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to
> the instances of java/lang/Class. This change restricts reflection from
> changing access to the classLoader field. In the spec,
> AccessibleObject.setAccessible() may throw SecurityException if the
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>
>
> Only AccessibleObject.java has changes from the previous version of this
> change.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Thanks,
> Coleen
>
> On 6/19/14, 11:01 PM, David Holmes wrote:
>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>> Hi Mandy,
>>>
>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>
>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>> Hi,
>>>>>
>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>> go away in 9 but ?).
>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>> private final field so you need to get priviledges to make it
>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>>
>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>> a field from being found using reflection. It might very well be
>>>>> the case that private and final is enough, I haven?t thought this
>>>>> through 100%. On the other hand, is there a reason to give users
>>>>> access through the field instead of having to use
>>>>> Class.getClassLoader()?
>>>>>
>>>> There are many getter methods that returns a private final field.
>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>> permission although it's a different security check (vs
>>>> "getClassLoader"
>>>> permission). Arguably before this new classLoader field, one could
>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>> loader.
>>>>
>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>> is too coarse-grained? I think the security team is looking into
>>>> the improvement in that regards.
>>>
>>> I think I?m a bit worried about two things, first as you wrote,
>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>> you could get the class loader through getClassLoader0() that
>>> shouldn?t be a new issue.
>>>
>>> The second thing is that IIRC there are ways to set a final field
>>> after initialization. I?m not sure we need to care about that either
>>> if you need Unsafe to do it.
>>
>> Normal reflection can set a final field if you can successfully call
>> setAccessible(true) on the Field object.
>>
>> David
>> -----
>>
>>
>>> cheers
>>> /Joel
>>>
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From coleen.phillimore at oracle.com Tue Jun 24 12:51:18 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 08:51:18 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A9358B.90102@gmail.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> <53A3A402.2060501@oracle.com>
<53A8BC28.6030008@oracle.com> <53A9358B.90102@gmail.com>
Message-ID: <53A97446.4020205@oracle.com>
Hi Peter,
On 6/24/14, 4:23 AM, Peter Levart wrote:
> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field
>> to the instances of java/lang/Class. This change restricts
>> reflection from changing access to the classLoader field. In the
>> spec, AccessibleObject.setAccessible() may throw SecurityException if
>> the accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>
>>
>> Only AccessibleObject.java has changes from the previous version of
>> this change.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>
> Hi Coleen,
>
> So hackers are prevented from hacking...
>
> Out of curiosity, what would happen if someone changed the classLoader
> field of some Class object? I guess VM still has it's own notion of
> the class' class loader, right? Only the code that directly uses the
> Class.getClassLoader() (and Unsafe.defineClass0) methods would be
> affected...
True, Class.getClassLoader() calls would be affected but we may use this
call for security checks. I'm not really an expert on this, but we
thought it wouldn't be safe to allow user access to classLoader.
>
> While we're at it, does this change in any way affect the GC logic?
> Will GC now navigate the classLoader field during marking but
> previously didn't ? Will this have any GC performance penalty ?
I actually ran this through our performance testing and got a good
improvement in one of the scimark benchmarks for no reason I could
explain (and lost the results), but none of the other tests were
affected. GC would have to mark this new field for full collections but
not young collections because it's only set during initialization. I
wouldn't expect this field to have any negative performance for GC.
Thanks,
Coleen
>
> Regards, Peter
>
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>>> should go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>> private final field so you need to get priviledges to make it
>>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>>> hides a field from being found using reflection. It might very
>>>>>> well be the case that private and final is enough, I haven?t
>>>>>> thought this through 100%. On the other hand, is there a reason
>>>>>> to give users access through the field instead of having to use
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs
>>>>> "getClassLoader"
>>>>> permission). Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained? I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote,
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but
>>>> since you could get the class loader through getClassLoader0() that
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field
>>>> after initialization. I?m not sure we need to care about that
>>>> either if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>
From coleen.phillimore at oracle.com Tue Jun 24 12:53:15 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 08:53:15 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A939C4.2080703@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> <53A3A402.2060501@oracle.com>
<53A8BC28.6030008@oracle.com> <53A939C4.2080703@oracle.com>
Message-ID: <53A974BB.1000809@oracle.com>
Fred,
Thank you for finding this. Yes, I meant to clean this up with the bug
to remove JVM_GetClassLoader but I should remove this with this change
instead, since the other change will be in hotspot only.
Yes, it's dead code.
Thanks!
Coleen
On 6/24/14, 4:41 AM, Frederic Parain wrote:
> Hi Coleen,
>
> It seems that there's still a reference to JVM_GetClassLoader
> in file jdk/src/share/native/common/check_code.c. The code looks
> like dead code, but it would be nice to clean it up.
>
> Thanks,
>
> Fred
>
> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field to
>> the instances of java/lang/Class. This change restricts reflection from
>> changing access to the classLoader field. In the spec,
>> AccessibleObject.setAccessible() may throw SecurityException if the
>> accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>
>>
>>
>> Only AccessibleObject.java has changes from the previous version of this
>> change.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>>> go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>> private final field so you need to get priviledges to make it
>>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>>> a field from being found using reflection. It might very well be
>>>>>> the case that private and final is enough, I haven?t thought this
>>>>>> through 100%. On the other hand, is there a reason to give users
>>>>>> access through the field instead of having to use
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs
>>>>> "getClassLoader"
>>>>> permission). Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained? I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote,
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>>> you could get the class loader through getClassLoader0() that
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field
>>>> after initialization. I?m not sure we need to care about that either
>>>> if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>
From mikael.gerdin at oracle.com Tue Jun 24 13:48:05 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 24 Jun 2014 15:48:05 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A97446.4020205@oracle.com>
References: <539F1066.8080302@oracle.com> <53A9358B.90102@gmail.com>
<53A97446.4020205@oracle.com>
Message-ID: <2657473.M2SI7jRyYi@mgerdin03>
On Tuesday 24 June 2014 08.51.18 Coleen Phillimore wrote:
> Hi Peter,
>
> On 6/24/14, 4:23 AM, Peter Levart wrote:
> > On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
> >> Please review a change to the JDK code for adding classLoader field
> >> to the instances of java/lang/Class. This change restricts
> >> reflection from changing access to the classLoader field. In the
> >> spec, AccessibleObject.setAccessible() may throw SecurityException if
> >> the accessibility of an object may not be changed:
> >>
> >> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObje
> >> ct.html#setAccessible(boolean)
> >>
> >>
> >> Only AccessibleObject.java has changes from the previous version of
> >> this change.
> >>
> >> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> >> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
> >>
> >> Thanks,
> >> Coleen
> >
> > Hi Coleen,
> >
> > So hackers are prevented from hacking...
> >
> > Out of curiosity, what would happen if someone changed the classLoader
> > field of some Class object? I guess VM still has it's own notion of
> > the class' class loader, right? Only the code that directly uses the
> > Class.getClassLoader() (and Unsafe.defineClass0) methods would be
> > affected...
>
> True, Class.getClassLoader() calls would be affected but we may use this
> call for security checks. I'm not really an expert on this, but we
> thought it wouldn't be safe to allow user access to classLoader.
>
> > While we're at it, does this change in any way affect the GC logic?
> > Will GC now navigate the classLoader field during marking but
> > previously didn't ? Will this have any GC performance penalty ?
>
> I actually ran this through our performance testing and got a good
> improvement in one of the scimark benchmarks for no reason I could
> explain (and lost the results), but none of the other tests were
> affected. GC would have to mark this new field for full collections but
> not young collections because it's only set during initialization. I
> wouldn't expect this field to have any negative performance for GC.
Peter has a good point actually. If the classLoader field is trustworthy we
can get rid of some code in InstanceMirrorKlass::{oop_follow_contents,
oop_oop_iterate} which currently picks up the class loader through the Klass*
field injected into java/lang/Class. It would be a nice simplification if the
ClassLoader objects were the only places where the GC would need to find the
link to the ClassLoaderData metadata.
But that won't work because anonymous (as in Unsafe.defineAnonymousClass)
classes don't interact with class loaders in the same way and have their own
ClassLoaderData objects.
/Mikael
>
> Thanks,
> Coleen
>
> > Regards, Peter
> >
> >> On 6/19/14, 11:01 PM, David Holmes wrote:
> >>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
> >>>> Hi Mandy,
> >>>>
> >>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
> >>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
> >>>>>>
> >>>>>> <coleen.phillimore at oracle.com> wrote:
> >>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
> >>>>>>>> Have you considered hiding the Class.classLoader field from
> >>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
> >>>>>>>> the idea of people poking at this field with Unsafe (which
> >>>>>>>> should go away in 9 but ?).
> >>>>>>>
> >>>>>>> I don't know how to hide the field from reflection. It's a
> >>>>>>> private final field so you need to get priviledges to make it
> >>>>>>> setAccessible. If you mean injecting it on the JVM side, the
> >>>>>>> reason for this change is so that the JIT compilers can inline
> >>>>>>> this call and not have to call into the JVM to get the class
> >>>>>>> loader.
> >>>>>>
> >>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
> >>>>>> hides a field from being found using reflection. It might very
> >>>>>> well be the case that private and final is enough, I haven?t
> >>>>>> thought this through 100%. On the other hand, is there a reason
> >>>>>> to give users access through the field instead of having to use
> >>>>>> Class.getClassLoader()?
> >>>>>
> >>>>> There are many getter methods that returns a private final field.
> >>>>> I'm not sure if hiding the field is necessary nor a good precedence
> >>>>> to set. Accessing a private field requires "accessDeclaredMember"
> >>>>> permission although it's a different security check (vs
> >>>>> "getClassLoader"
> >>>>> permission). Arguably before this new classLoader field, one could
> >>>>> call Class.getClassLoader0() via reflection to get a hold of class
> >>>>> loader.
> >>>>>
> >>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
> >>>>> is too coarse-grained? I think the security team is looking into
> >>>>> the improvement in that regards.
> >>>>
> >>>> I think I?m a bit worried about two things, first as you wrote,
> >>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but
> >>>> since you could get the class loader through getClassLoader0() that
> >>>> shouldn?t be a new issue.
> >>>>
> >>>> The second thing is that IIRC there are ways to set a final field
> >>>> after initialization. I?m not sure we need to care about that
> >>>> either if you need Unsafe to do it.
> >>>
> >>> Normal reflection can set a final field if you can successfully call
> >>> setAccessible(true) on the Field object.
> >>>
> >>> David
> >>> -----
> >>>
> >>>> cheers
> >>>> /Joel
From stefan.karlsson at oracle.com Tue Jun 24 13:52:22 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 24 Jun 2014 15:52:22 +0200
Subject: RFR: 8047326: Add a version of CompiledIC_at that doesn't create
a new RelocIterator
In-Reply-To: <53A3038C.9020004@oracle.com>
References: <53A2DB59.9050605@oracle.com> <53A3038C.9020004@oracle.com>
Message-ID: <53A98296.5090604@oracle.com>
Hi all,
Could someone from the Compiler team take a look and review/comment on
this patch?
thanks,
StefanK
On 2014-06-19 17:36, Stefan Karlsson wrote:
> This was meant for the hotspot-dev list. BCC:ing hotspot-gc-dev.
>
> On 2014-06-19 14:45, Stefan Karlsson wrote:
>> Hi all,
>>
>> I have a patch that we have been using in the G1 Class Unloading
>> project to lower the remark times. This changes Compiler code, so I
>> would like to get feedback from the Compiler team.
>>
>> http://cr.openjdk.java.net/~stefank/8047362/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8047362
>>
>> The patch builds upon the patch in:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014358.html
>>
>>
>> Summary from the bug report:
>> ---
>> Creation of RelocIterators show up high in profiles of the remark
>> phase, in the G1 Class Unloading project.
>>
>> There's a pattern in the nmethod/codecache code to create a
>> RelocIterator and then materialize a CompiledIC:
>>
>> RelocIterator iter(this, low_boundary);
>> while(iter.next()) {
>> if (iter.type() == relocInfo::virtual_call_type) {
>> CompiledIC *ic = CompiledIC_at(iter.reloc());
>>
>> CompiledIC_at is implemented as:
>> new CompiledIC(call_site->code(), nativeCall_at(call_site->addr()));
>>
>> And one of the first thing CompiledIC::CompiledIC(const nmethod* nm,
>> NativeCall* call) does is to create a new RelocIterator:
>> ...
>> address ic_call = call->instruction_address();
>> ...
>> RelocIterator iter(nm, ic_call, ic_call+1);
>> bool ret = iter.next();
>> assert(ret == true, "relocInfo must exist at this address");
>> assert(iter.addr() == ic_call, "must find ic_call");
>>
>> I would like to propose that we pass down the RelocIterator that we
>> already have, instead of creating a new.
>> ---
>>
>>
>> I've previously received feedback that this seems like reasonable
>> thing to do, but that the parameter to the new CompileIC_at should
>> take a const RelocIterator* instead of RelocIterator*. I couldn't do
>> that without changing a significant amount of Compiler code, so I
>> have left it out for now. Any opinions on how to handle that?
>>
>>
>> To give an idea of the performance difference, I temporarily added
>> the following code:
>> void CodeCache::iterate_through_CIs(int style) {
>> int count;
>> FOR_ALL_ALIVE_NMETHODS(nm) {
>> RelocIterator iter(nm);
>> while(iter.next()) {
>> if (iter.type() == relocInfo::virtual_call_type ||
>> iter.type() == relocInfo::opt_virtual_call_type) {
>> if (style > 0) {
>> CompiledIC *ic = style == 1 ? CompiledIC_at(&iter) :
>> CompiledIC_at(iter.reloc());
>> if (ic->ic_destination() == (address)0xdeadb000) {
>> gclog_or_tty->print_cr("ShouldNotReachHere");
>> }
>> }
>> }
>> }
>> }
>> }
>>
>> and then measured how long time it took to execute
>> iterate_through_CIs(style) 1000 times with style == {0, 1, 2}.
>>
>> The results are:
>> iterate_through_CIs(0): 1.210833 s // No CompiledICs created
>> iterate_through_CIs(1): 1.976557 s // New style
>> iterate_through_CIs(2): 9.924209 s // Old style
>>
>>
>> Testing:
>> A similar version has been used and thoroughly been tested together
>> with the other G1 Class Unloading changes. This exact version has so
>> far only been tested with Kitchensink and SpecJVM2008
>> compiler.compiler. What test lists would be appropriate to test this
>> with?
>>
>>
>> thanks,
>> StefanK
>>
>
From coleen.phillimore at oracle.com Tue Jun 24 15:03:29 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 11:03:29 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <2657473.M2SI7jRyYi@mgerdin03>
References: <539F1066.8080302@oracle.com> <53A9358B.90102@gmail.com>
<53A97446.4020205@oracle.com> <2657473.M2SI7jRyYi@mgerdin03>
Message-ID: <53A99341.2000301@oracle.com>
Mikael, see below.
On 6/24/14, 9:48 AM, Mikael Gerdin wrote:
> On Tuesday 24 June 2014 08.51.18 Coleen Phillimore wrote:
>> Hi Peter,
>>
>> On 6/24/14, 4:23 AM, Peter Levart wrote:
>>> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>>> Please review a change to the JDK code for adding classLoader field
>>>> to the instances of java/lang/Class. This change restricts
>>>> reflection from changing access to the classLoader field. In the
>>>> spec, AccessibleObject.setAccessible() may throw SecurityException if
>>>> the accessibility of an object may not be changed:
>>>>
>>>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObje
>>>> ct.html#setAccessible(boolean)
>>>>
>>>>
>>>> Only AccessibleObject.java has changes from the previous version of
>>>> this change.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>>>
>>>> Thanks,
>>>> Coleen
>>> Hi Coleen,
>>>
>>> So hackers are prevented from hacking...
>>>
>>> Out of curiosity, what would happen if someone changed the classLoader
>>> field of some Class object? I guess VM still has it's own notion of
>>> the class' class loader, right? Only the code that directly uses the
>>> Class.getClassLoader() (and Unsafe.defineClass0) methods would be
>>> affected...
>> True, Class.getClassLoader() calls would be affected but we may use this
>> call for security checks. I'm not really an expert on this, but we
>> thought it wouldn't be safe to allow user access to classLoader.
>>
>>> While we're at it, does this change in any way affect the GC logic?
>>> Will GC now navigate the classLoader field during marking but
>>> previously didn't ? Will this have any GC performance penalty ?
>> I actually ran this through our performance testing and got a good
>> improvement in one of the scimark benchmarks for no reason I could
>> explain (and lost the results), but none of the other tests were
>> affected. GC would have to mark this new field for full collections but
>> not young collections because it's only set during initialization. I
>> wouldn't expect this field to have any negative performance for GC.
> Peter has a good point actually. If the classLoader field is trustworthy we
> can get rid of some code in InstanceMirrorKlass::{oop_follow_contents,
> oop_oop_iterate} which currently picks up the class loader through the Klass*
> field injected into java/lang/Class. It would be a nice simplification if the
> ClassLoader objects were the only places where the GC would need to find the
> link to the ClassLoaderData metadata.
>
> But that won't work because anonymous (as in Unsafe.defineAnonymousClass)
> classes don't interact with class loaders in the same way and have their own
> ClassLoaderData objects.
Yes, one version of this patch removed class_loader_data from
InstanceKlass so we'd be space-neutral but since there isn't a 1-1
relationship to class_loader and ClassLoaderData for Unsafe anonymous
classes, it doesn't work. We might think of a way around this because
we want to go in this direction.
Thanks,
Coleen
>
> /Mikael
>
>> Thanks,
>> Coleen
>>
>>> Regards, Peter
>>>
>>>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>>>> Hi Mandy,
>>>>>>
>>>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>>>
>>>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>>>>> should go away in 9 but ?).
>>>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>>>> private final field so you need to get priviledges to make it
>>>>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>>>> loader.
>>>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>>>>> hides a field from being found using reflection. It might very
>>>>>>>> well be the case that private and final is enough, I haven?t
>>>>>>>> thought this through 100%. On the other hand, is there a reason
>>>>>>>> to give users access through the field instead of having to use
>>>>>>>> Class.getClassLoader()?
>>>>>>> There are many getter methods that returns a private final field.
>>>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>>>> permission although it's a different security check (vs
>>>>>>> "getClassLoader"
>>>>>>> permission). Arguably before this new classLoader field, one could
>>>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>>>> loader.
>>>>>>>
>>>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>>>> is too coarse-grained? I think the security team is looking into
>>>>>>> the improvement in that regards.
>>>>>> I think I?m a bit worried about two things, first as you wrote,
>>>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but
>>>>>> since you could get the class loader through getClassLoader0() that
>>>>>> shouldn?t be a new issue.
>>>>>>
>>>>>> The second thing is that IIRC there are ways to set a final field
>>>>>> after initialization. I?m not sure we need to care about that
>>>>>> either if you need Unsafe to do it.
>>>>> Normal reflection can set a final field if you can successfully call
>>>>> setAccessible(true) on the Field object.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> cheers
>>>>>> /Joel
From coleen.phillimore at oracle.com Tue Jun 24 15:11:49 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Jun 2014 11:11:49 -0400
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A939C4.2080703@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> <53A3A402.2060501@oracle.com>
<53A8BC28.6030008@oracle.com> <53A939C4.2080703@oracle.com>
Message-ID: <53A99535.4050809@oracle.com>
On 6/24/14, 4:41 AM, Frederic Parain wrote:
> Hi Coleen,
>
> It seems that there's still a reference to JVM_GetClassLoader
> in file jdk/src/share/native/common/check_code.c. The code looks
> like dead code, but it would be nice to clean it up.
I removed this code. There are no other instances of the macro
BROKEN_JAVAC. I update the copyrights when I commit the changeset.
http://cr.openjdk.java.net/~coleenp/6642881_jdk_5/
Thanks!
Coleen
>
> Thanks,
>
> Fred
>
> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>
>> Please review a change to the JDK code for adding classLoader field to
>> the instances of java/lang/Class. This change restricts reflection from
>> changing access to the classLoader field. In the spec,
>> AccessibleObject.setAccessible() may throw SecurityException if the
>> accessibility of an object may not be changed:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>
>>
>>
>> Only AccessibleObject.java has changes from the previous version of this
>> change.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Thanks,
>> Coleen
>>
>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>> Hi Mandy,
>>>>
>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>
>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>>> go away in 9 but ?).
>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>> private final field so you need to get priviledges to make it
>>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>> loader.
>>>>>>>
>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>>> a field from being found using reflection. It might very well be
>>>>>> the case that private and final is enough, I haven?t thought this
>>>>>> through 100%. On the other hand, is there a reason to give users
>>>>>> access through the field instead of having to use
>>>>>> Class.getClassLoader()?
>>>>>>
>>>>> There are many getter methods that returns a private final field.
>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>> permission although it's a different security check (vs
>>>>> "getClassLoader"
>>>>> permission). Arguably before this new classLoader field, one could
>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>> loader.
>>>>>
>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>> is too coarse-grained? I think the security team is looking into
>>>>> the improvement in that regards.
>>>>
>>>> I think I?m a bit worried about two things, first as you wrote,
>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>>> you could get the class loader through getClassLoader0() that
>>>> shouldn?t be a new issue.
>>>>
>>>> The second thing is that IIRC there are ways to set a final field
>>>> after initialization. I?m not sure we need to care about that either
>>>> if you need Unsafe to do it.
>>>
>>> Normal reflection can set a final field if you can successfully call
>>> setAccessible(true) on the Field object.
>>>
>>> David
>>> -----
>>>
>>>
>>>> cheers
>>>> /Joel
>>>>
>>
>
From frederic.parain at oracle.com Tue Jun 24 15:14:58 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 24 Jun 2014 17:14:58 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A99535.4050809@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> <53A3A402.2060501@oracle.com>
<53A8BC28.6030008@oracle.com> <53A939C4.2080703@oracle.com>
<53A99535.4050809@oracle.com>
Message-ID: <53A995F2.9090502@oracle.com>
Looks good to me.
Thanks,
Fred
On 24/06/2014 17:11, Coleen Phillimore wrote:
>
> On 6/24/14, 4:41 AM, Frederic Parain wrote:
>> Hi Coleen,
>>
>> It seems that there's still a reference to JVM_GetClassLoader
>> in file jdk/src/share/native/common/check_code.c. The code looks
>> like dead code, but it would be nice to clean it up.
>
> I removed this code. There are no other instances of the macro
> BROKEN_JAVAC. I update the copyrights when I commit the changeset.
>
> http://cr.openjdk.java.net/~coleenp/6642881_jdk_5/
>
> Thanks!
> Coleen
>>
>> Thanks,
>>
>> Fred
>>
>> On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>>>
>>> Please review a change to the JDK code for adding classLoader field to
>>> the instances of java/lang/Class. This change restricts reflection from
>>> changing access to the classLoader field. In the spec,
>>> AccessibleObject.setAccessible() may throw SecurityException if the
>>> accessibility of an object may not be changed:
>>>
>>> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>>>
>>>
>>>
>>> Only AccessibleObject.java has changes from the previous version of this
>>> change.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 6/19/14, 11:01 PM, David Holmes wrote:
>>>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>>>> Hi Mandy,
>>>>>
>>>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>>
>>>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>>>> the idea of people poking at this field with Unsafe (which should
>>>>>>>>> go away in 9 but ?).
>>>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>>>> private final field so you need to get priviledges to make it
>>>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>>>> this call and not have to call into the JVM to get the class
>>>>>>>> loader.
>>>>>>>>
>>>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that hides
>>>>>>> a field from being found using reflection. It might very well be
>>>>>>> the case that private and final is enough, I haven?t thought this
>>>>>>> through 100%. On the other hand, is there a reason to give users
>>>>>>> access through the field instead of having to use
>>>>>>> Class.getClassLoader()?
>>>>>>>
>>>>>> There are many getter methods that returns a private final field.
>>>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>>>> permission although it's a different security check (vs
>>>>>> "getClassLoader"
>>>>>> permission). Arguably before this new classLoader field, one could
>>>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>>>> loader.
>>>>>>
>>>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>>>> is too coarse-grained? I think the security team is looking into
>>>>>> the improvement in that regards.
>>>>>
>>>>> I think I?m a bit worried about two things, first as you wrote,
>>>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>>>> you could get the class loader through getClassLoader0() that
>>>>> shouldn?t be a new issue.
>>>>>
>>>>> The second thing is that IIRC there are ways to set a final field
>>>>> after initialization. I?m not sure we need to care about that either
>>>>> if you need Unsafe to do it.
>>>>
>>>> Normal reflection can set a final field if you can successfully call
>>>> setAccessible(true) on the Field object.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> cheers
>>>>> /Joel
>>>>>
>>>
>>
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From peter.levart at gmail.com Tue Jun 24 08:23:39 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Jun 2014 10:23:39 +0200
Subject: RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <53A8BC28.6030008@oracle.com>
References: <539F1066.8080302@oracle.com> <6C677BF2-E257-48C9-B589-A668A8D939CC@oracle.com> <53A3301B.7070405@oracle.com> <92581C73-CE4D-44E0-B5D4-70300FF4100E@oracle.com> <53A34949.6040607@oracle.com> <105F29DA-7744-4D53-8AB5-36EE669ED417@oracle.com> <53A3A402.2060501@oracle.com>
<53A8BC28.6030008@oracle.com>
Message-ID: <53A9358B.90102@gmail.com>
On 06/24/2014 01:45 AM, Coleen Phillimore wrote:
>
> Please review a change to the JDK code for adding classLoader field to
> the instances of java/lang/Class. This change restricts reflection
> from changing access to the classLoader field. In the spec,
> AccessibleObject.setAccessible() may throw SecurityException if the
> accessibility of an object may not be changed:
>
> http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean)
>
>
> Only AccessibleObject.java has changes from the previous version of
> this change.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk_4/
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Thanks,
> Coleen
Hi Coleen,
So hackers are prevented from hacking...
Out of curiosity, what would happen if someone changed the classLoader
field of some Class object? I guess VM still has it's own notion of the
class' class loader, right? Only the code that directly uses the
Class.getClassLoader() (and Unsafe.defineClass0) methods would be
affected...
While we're at it, does this change in any way affect the GC logic? Will
GC now navigate the classLoader field during marking but previously
didn't ? Will this have any GC performance penalty ?
Regards, Peter
>
> On 6/19/14, 11:01 PM, David Holmes wrote:
>> On 20/06/2014 6:53 AM, Joel Borggr?n-Franck wrote:
>>> Hi Mandy,
>>>
>>> On 19 jun 2014, at 22:34, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>
>>>> On 6/19/14 12:34 PM, Joel Borggr?n-Franck wrote:
>>>>> Hi,
>>>>>
>>>>> On 19 jun 2014, at 20:46, Coleen Phillimore
>>>>> <coleen.phillimore at oracle.com> wrote:
>>>>>> On 6/17/14, 12:38 AM, Joel Borggr?n-Franck wrote:
>>>>>>> Have you considered hiding the Class.classLoader field from
>>>>>>> reflection? I?m not sure it is necessary but I?m not to keen on
>>>>>>> the idea of people poking at this field with Unsafe (which
>>>>>>> should go away in 9 but ?).
>>>>>> I don't know how to hide the field from reflection. It's a
>>>>>> private final field so you need to get priviledges to make it
>>>>>> setAccessible. If you mean injecting it on the JVM side, the
>>>>>> reason for this change is so that the JIT compilers can inline
>>>>>> this call and not have to call into the JVM to get the class loader.
>>>>>>
>>>>> There is sun.reflect.Reflection.registerFieldsToFilter() that
>>>>> hides a field from being found using reflection. It might very
>>>>> well be the case that private and final is enough, I haven?t
>>>>> thought this through 100%. On the other hand, is there a reason to
>>>>> give users access through the field instead of having to use
>>>>> Class.getClassLoader()?
>>>>>
>>>> There are many getter methods that returns a private final field.
>>>> I'm not sure if hiding the field is necessary nor a good precedence
>>>> to set. Accessing a private field requires "accessDeclaredMember"
>>>> permission although it's a different security check (vs
>>>> "getClassLoader"
>>>> permission). Arguably before this new classLoader field, one could
>>>> call Class.getClassLoader0() via reflection to get a hold of class
>>>> loader.
>>>>
>>>> Perhaps you are concerned that the "accessDeclaredMember" permission
>>>> is too coarse-grained? I think the security team is looking into
>>>> the improvement in that regards.
>>>
>>> I think I?m a bit worried about two things, first as you wrote,
>>> ?accessDeclaredMember? isn?t the same as ?getClassLoader?, but since
>>> you could get the class loader through getClassLoader0() that
>>> shouldn?t be a new issue.
>>>
>>> The second thing is that IIRC there are ways to set a final field
>>> after initialization. I?m not sure we need to care about that either
>>> if you need Unsafe to do it.
>>
>> Normal reflection can set a final field if you can successfully call
>> setAccessible(true) on the Field object.
>>
>> David
>> -----
>>
>>
>>> cheers
>>> /Joel
>>>
>
From mikael.vidstedt at oracle.com Wed Jun 25 03:49:37 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 24 Jun 2014 20:49:37 -0700
Subject: RFR(M): 8047740: Add hotspot testset to jprt.properties
In-Reply-To: <53A92A2A.2020907@oracle.com>
References: <53A8BEB7.6080300@oracle.com> <53A92A2A.2020907@oracle.com>
Message-ID: <53AA46D1.1060704@oracle.com>
I noticed that the logic for jprt.push.sync was inverted (should be
false for a hotspot job and true otherwise), so I'll fix that before I
commit!
Thanks for the review!
/Mikael
On 2014-06-24 00:35, David Holmes wrote:
> Looks good to me!
>
> Thanks,
> David
>
> On 24/06/2014 9:56 AM, Mikael Vidstedt wrote:
>>
>> All,
>>
>> Please review the below change which adds a "hotspot" testset to the top
>> level jprt.properties and makes it possible to do the equivalent of a
>> hotspot push job but from the top level -- building the whole/full JDK
>> but running the same old tests. The change should not change any
>> existing use cases, so unless using the hotspot testset specifically
>> everything should work exactly as it does today.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047740
>> Webrev:
>> http://cr.openjdk.java.net/~mikael/webrevs/8047740/webrev.00/webrev/
>>
>> Note that the name of the testset is used to control not only which
>> platforms are being built and tested, but also whether a mercurial sync
>> should be made after build/before push - specifically, the testset is
>> "hotspot" handled differently from the other testsets.
>>
>> I have manually verified that when running with the various testsets the
>> build and test target sets are the same as before the patch.
>>
>> Thanks,
>> Mikael
>>
From david.holmes at oracle.com Wed Jun 25 11:40:19 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Jun 2014 21:40:19 +1000
Subject: Speed difference between EA versions and official distributions.
In-Reply-To: <CALdaLZt_mnjVRc5NheJVPAZiBZtDLyYBmNd3CS1YG3cf+nFiVQ@mail.gmail.com>
References: <CALdaLZt_mnjVRc5NheJVPAZiBZtDLyYBmNd3CS1YG3cf+nFiVQ@mail.gmail.com>
Message-ID: <53AAB523.8080709@oracle.com>
Hi Ahmet,
On 25/06/2014 9:15 PM, Ahmet A. Akin wrote:
> Hello,
>
> I hope this is the correct place to ask.
No, the discuss list is for "General discussion about the OpenJDK
Community":
http://mail.openjdk.java.net/mailman/listinfo
I've cc'd the hotspot-dev list as a better starting point, and the
discuss list should be dropped from replies.
> Recently I tested our Java speech
> recognition engine speed with several Java versions.
>
> Two JDK 8 EA builds ( 1.8.0-ea-b109 and 1.8.0_20-ea-b19 )
> One Stable Oracle JDK 8 release: ( 1.8.0_05-b13 )
> One Stable Open JDK 7 release: ( IcedTea 7u55-2.4.7 )
>
> And I observed that both Java-8 EA versions runs %6-8 faster than the
> stable Oracle JDK 8 and Open JDK 7 releases. What can be the reason? Do EA
> builds and Oracle official releases use different compilers? Or is there
> something else I should be checking? What do you suggest?
There can be a lot of factors involved but EA releases are not
deliberately different other than they are, by their nature, not as
complete as the GA release will be. The compiler might be different if a
compiler update is planned for a release and you happen to have taken an
EA build from before the change.
Sometimes problems are discovered with code that requires a fix that
lowers performance prior to GA. Developers then look for ways to get the
performance back while maintaining correctness. So, as a purely
hypothetical example, 8-b109 may have had a fast but incorrect piece of
code, 8-b132 (the GA build) may have had a correct but slower version of
the code, and then for 8u20 a new fix was found that improved the
performance.
An EA build may have a partially implemented feature, and once the
feature is complete, the performance has changed.
To know exactly what the differences are would require a lot of detailed
benchmarking of each build to create a performance profile for the
release and then try to see what changes may have contributed to the
performance deltas.
Cheers,
David
> Environment: Ubuntu 12.04 64-bit, Intel i7-3770 3.4Ghz x 8
>
> Best,
>
> Ahmet
>
From ahmetaa at gmail.com Wed Jun 25 12:16:09 2014
From: ahmetaa at gmail.com (Ahmet A. Akin)
Date: Wed, 25 Jun 2014 15:16:09 +0300
Subject: Speed difference between EA versions and official distributions.
In-Reply-To: <53AAB523.8080709@oracle.com>
References: <CALdaLZt_mnjVRc5NheJVPAZiBZtDLyYBmNd3CS1YG3cf+nFiVQ@mail.gmail.com>
<53AAB523.8080709@oracle.com>
Message-ID: <CALdaLZt1M1kZ0ykeNou6d2pcRef_Fa49EapQnoc=yJ0QxQKC1A@mail.gmail.com>
Hello David.
On Wed, Jun 25, 2014 at 2:40 PM, David Holmes <david.holmes at oracle.com>
wrote:
> Hi Ahmet,
>
>
> On 25/06/2014 9:15 PM, Ahmet A. Akin wrote:
>
>> Hello,
>>
>> I hope this is the correct place to ask.
>>
>
> No, the discuss list is for "General discussion about the OpenJDK
> Community":
>
> http://mail.openjdk.java.net/mailman/listinfo
>
> I've cc'd the hotspot-dev list as a better starting point, and the discuss
> list should be dropped from replies.
>
> Recently I tested our Java speech
>> recognition engine speed with several Java versions.
>>
>> Two JDK 8 EA builds ( 1.8.0-ea-b109 and 1.8.0_20-ea-b19 )
>> One Stable Oracle JDK 8 release: ( 1.8.0_05-b13 )
>> One Stable Open JDK 7 release: ( IcedTea 7u55-2.4.7 )
>>
>> And I observed that both Java-8 EA versions runs %6-8 faster than the
>> stable Oracle JDK 8 and Open JDK 7 releases. What can be the reason? Do EA
>> builds and Oracle official releases use different compilers? Or is there
>> something else I should be checking? What do you suggest?
>>
>
> There can be a lot of factors involved but EA releases are not
> deliberately different other than they are, by their nature, not as
> complete as the GA release will be. The compiler might be different if a
> compiler update is planned for a release and you happen to have taken an EA
> build from before the change.
>
> Sometimes problems are discovered with code that requires a fix that
> lowers performance prior to GA. Developers then look for ways to get the
> performance back while maintaining correctness. So, as a purely
> hypothetical example, 8-b109 may have had a fast but incorrect piece of
> code, 8-b132 (the GA build) may have had a correct but slower version of
> the code, and then for 8u20 a new fix was found that improved the
> performance.
>
> An EA build may have a partially implemented feature, and once the feature
> is complete, the performance has changed.
>
> To know exactly what the differences are would require a lot of detailed
> benchmarking of each build to create a performance profile for the release
> and then try to see what changes may have contributed to the performance
> deltas.
First, sorry for sending this to the wrong list and thanks for the logical
explanation. Unfortunately code and algorithms are quite large and it will
be hard to demonstrate the slow down with a sample code. There are cache
sensitive numerical calculations, millions of hash, graph search
operations. But anyway I will give some time and try to write a small test
code for this.
Regards,
Ahmet
>
> Cheers,
> David
>
>
> Environment: Ubuntu 12.04 64-bit, Intel i7-3770 3.4Ghz x 8
>>
>> Best,
>>
>> Ahmet
>>
>>
From serguei.spitsyn at oracle.com Wed Jun 25 13:57:34 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 25 Jun 2014 06:57:34 -0700
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type
check
Message-ID: <53AAD54E.8090804@oracle.com>
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8013942
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1
Summary:
This is a Nightly Stabilization issue.
The problem is that the JVMTI GetLocalObject() function is hitting
the assert
as the type of the local at current bci is not T_OBJECT as expected.
It is because this local is alive only in a narrow scope of one
condition in the method but current bci is out of this csope.
A fragment from the target method:
static Class<?> canonicalize(Class<?> t, int how) {
Class<?> ct; <== The local
if (t == Object.class) {
// no change, ever
} else if (!t.isPrimitive()) {
switch (how) {
case UNWRAP:
ct = Wrapper.asPrimitiveType(t); <== Initialized here
if (ct != t) return ct;
break;
case RAW_RETURN:
case ERASE:
return Object.class;
}
} else if (t == void.class) { <== The
GetLocalObject() is called with bci in this block
// no change, usually
switch (how) {
case RAW_RETURN:
return int.class;
case WRAP:
return Void.class;
}
} else {
. . .
The local 'ct' is only alive in the block of condition "if
(!t.isPrimitive())".
However, it is dead local in the next block.
The fix suggested in the webrev above is to use the oop_mask for the
method's current bci.
It tells when the local is dead in the scope of this bci.
Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
The fix also includes the tweeks which are necessary to enable the
InterpreterOopMap.is_dead()
function in the product mode as it was originally defined only under
"#ifdef ENABLE_ZAP_DEAD_LOCALS".
This makes the code in the oopMapCache.?pp a little bit more simple.
Testing:
Running the failing tests: vm.mlvm.indy.func.jvmti
In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and amd64
Thanks,
Serguei
From mikael.gerdin at oracle.com Wed Jun 25 14:44:07 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 25 Jun 2014 16:44:07 +0200
Subject: Speed difference between EA versions and official distributions.
In-Reply-To: <CALdaLZt1M1kZ0ykeNou6d2pcRef_Fa49EapQnoc=yJ0QxQKC1A@mail.gmail.com>
References: <CALdaLZt_mnjVRc5NheJVPAZiBZtDLyYBmNd3CS1YG3cf+nFiVQ@mail.gmail.com>
<53AAB523.8080709@oracle.com>
<CALdaLZt1M1kZ0ykeNou6d2pcRef_Fa49EapQnoc=yJ0QxQKC1A@mail.gmail.com>
Message-ID: <8620840.hpv15LKfFX@mgerdin03>
On Wednesday 25 June 2014 15.16.09 Ahmet A. Akin wrote:
> Hello David.
>
> On Wed, Jun 25, 2014 at 2:40 PM, David Holmes <david.holmes at oracle.com>
>
> wrote:
> > Hi Ahmet,
> >
> > On 25/06/2014 9:15 PM, Ahmet A. Akin wrote:
> >> Hello,
> >>
> >> I hope this is the correct place to ask.
> >
> > No, the discuss list is for "General discussion about the OpenJDK
> > Community":
> >
> > http://mail.openjdk.java.net/mailman/listinfo
> >
> > I've cc'd the hotspot-dev list as a better starting point, and the discuss
> > list should be dropped from replies.
> >
> > Recently I tested our Java speech
> >
> >> recognition engine speed with several Java versions.
> >>
> >> Two JDK 8 EA builds ( 1.8.0-ea-b109 and 1.8.0_20-ea-b19 )
> >> One Stable Oracle JDK 8 release: ( 1.8.0_05-b13 )
> >> One Stable Open JDK 7 release: ( IcedTea 7u55-2.4.7 )
> >>
> >> And I observed that both Java-8 EA versions runs %6-8 faster than the
> >> stable Oracle JDK 8 and Open JDK 7 releases. What can be the reason? Do
> >> EA
> >> builds and Oracle official releases use different compilers? Or is there
> >> something else I should be checking? What do you suggest?
> >
> > There can be a lot of factors involved but EA releases are not
> > deliberately different other than they are, by their nature, not as
> > complete as the GA release will be. The compiler might be different if a
> > compiler update is planned for a release and you happen to have taken an
> > EA
> > build from before the change.
> >
> > Sometimes problems are discovered with code that requires a fix that
> > lowers performance prior to GA. Developers then look for ways to get the
> > performance back while maintaining correctness. So, as a purely
> > hypothetical example, 8-b109 may have had a fast but incorrect piece of
> > code, 8-b132 (the GA build) may have had a correct but slower version of
> > the code, and then for 8u20 a new fix was found that improved the
> > performance.
> >
> > An EA build may have a partially implemented feature, and once the feature
> > is complete, the performance has changed.
> >
> > To know exactly what the differences are would require a lot of detailed
> > benchmarking of each build to create a performance profile for the release
> > and then try to see what changes may have contributed to the performance
> > deltas.
>
> First, sorry for sending this to the wrong list and thanks for the logical
> explanation. Unfortunately code and algorithms are quite large and it will
> be hard to demonstrate the slow down with a sample code. There are cache
> sensitive numerical calculations, millions of hash, graph search
> operations. But anyway I will give some time and try to write a small test
> code for this.
A quick experiment could be to run 1.8.0_05-b13 with
-XX:+EliminateAutoBox
That optimization was disabled because of a bug late in 8 and the bug was
fixed in 1.8.0_20 and the flag was re-enabled.
/Mikael
>
> Regards,
>
> Ahmet
>
> > Cheers,
> > David
> >
> > Environment: Ubuntu 12.04 64-bit, Intel i7-3770 3.4Ghz x 8
> >
> >> Best,
> >>
> >> Ahmet
From andrey.x.zakharov at oracle.com Wed Jun 25 15:08:10 2014
From: andrey.x.zakharov at oracle.com (Andrey Zakharov)
Date: Wed, 25 Jun 2014 19:08:10 +0400
Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file
to JTwork/scratch/sun/hotspot
In-Reply-To: <539F1404.6070307@oracle.com>
References: <536B7CF0.6010508@oracle.com> <536B9E36.6090802@oracle.com>
<536BA28D.7030808@oracle.com> <3503372.bSN5QEX8PY@mgerdin03>
<5371F734.6090809@oracle.com> <537CC81C.6010905@oracle.com>
<537DB9B0.8010200@oracle.com> <537F33CB.5050505@oracle.com>
<5395CBE3.5030502@oracle.com> <539727A6.5030307@oracle.com>
<539F1404.6070307@oracle.com>
Message-ID: <53AAE5DA.2030700@oracle.com>
Hi, all
So in progress of previous email -
webrev:
http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/
Thanks.
On 16.06.2014 19:57, Andrey Zakharov wrote:
> Hi, all
> So issue is that when tests with WhiteBox API has been invoked with
> -Xverify:all it fails with Exception java.lang.NoClassDefFoundError:
> sun/hotspot/WhiteBox$WhiteBoxPermission
> Solutions that are observed:
> 1. Copy WhiteBoxPermission with WhiteBox. But
> >> Perhaps this is a good time to get rid of ClassFileInstaller
> altogether?
>
> 2. Using bootclasspath to hook pre-built whitebox (due @library
> /testlibrary/whitebox) . Some tests has @run main/othervm, some uses
> ProcessBuilder.
> - main/othervm/bootclasspath adds ${test.src} and ${test.classes}to
> options.
> - With ProcessBuilder we can just add ${test.classes}
> Question here is, can it broke some tests ? While testing this, I
> found only https://bugs.openjdk.java.net/browse/JDK-8046231, others
> looks fine.
>
> 3. Make ClassFileInstaller deal with inner classes like that:
> diff -r 6ed24aedeef0 -r c01651363ba8
> test/testlibrary/ClassFileInstaller.java
> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 19:02:56
> 2014 +0400
> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 18:18:11
> 2014 +0400
> @@ -50,6 +50,16 @@
> }
> // Create the class file
> Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING);
> +
> + for (Class<?> cls :
> Class.forName(arg).getDeclaredClasses()) {
> + //if (!Modifier.isStatic(cls.getModifiers())) {
> + String pathNameSub =
> cls.getCanonicalName().replace('.', '/').concat(".class");
> + Path pathSub = Paths.get(pathNameSub);
> + InputStream streamSub =
> cl.getResourceAsStream(pathNameSub);
> + Files.copy(streamSub, pathSub,
> StandardCopyOption.REPLACE_EXISTING);
> + //}
> + }
> +
> }
> }
> }
>
> Works fine for ordinary classes, but fails for WhiteBox due
> Class.forName initiate Class. WhiteBox has "static" section, and
> initialization fails as it cannot bind to native methods
> "registerNatives" and so on.
>
>
> So, lets return to first one option? Just add everywhere
> * @run main ClassFileInstaller sun.hotspot.WhiteBox
> + * @run main ClassFileInstaller sun.hotspot.WhiteBox$WhiteBoxPermission
>
> Thanks.
>
>
> On 10.06.2014 19:43, Igor Ignatyev wrote:
>> Andrey,
>>
>> I don't like this idea, since it completely changes the tests.
>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, so the
>> tests whose main idea was testing WB methods themselves (sanity,
>> compiler/whitebox, ...) don't check that it's possible to use WB when
>> the application isn't in BCP.
>>
>> Igor
>>
>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote:
>>> Hi, everybody
>>> I have tested my changes on major platforms and found one bug, filed:
>>> https://bugs.openjdk.java.net/browse/JDK-8046231
>>> Also, i did another try to make ClassFileInstaller to copy all inner
>>> classes within parent, but this fails for WhiteBox due its static
>>> "registerNatives" dependency.
>>>
>>> Please, review suggested changes:
>>> - replace ClassFileInstaller and run/othervm with
>>> "run/othervm/bootclasspath".
>>> bootclasspath parameter for othervm adds-Xbootclasspath/a:
>>> option with ${test.src} and ${test.classes}according to
>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/share/classes/com/sun/javatest/regtest/MainAction.java.
>>>
>>> Is this suitable for our needs - give to test compiled WhiteBox?
>>> - replace explicit -Xbootclasspath option values (".") in
>>> ProcessBuilder invocations to ${test.classes} where WhiteBox has been
>>> compiled.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8011397
>>> Thanks.
>>>
>>>
>>> On 23.05.2014 15:40, Andrey Zakharov wrote:
>>>>
>>>> On 22.05.2014 12:47, Igor Ignatyev wrote:
>>>>> Andrey,
>>>>>
>>>>> 1. You changed dozen of tests, have you tested your changes?
>>>> Locally, aurora on the way.
>>>>>
>>>>> 2. Your changes of year in copyright is wrong. it has to be
>>>>> $first_year, [$last_year, ], see Mark's email[1] for details.
>>>>>
>>>>> [1]
>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.html
>>>> Thanks, fixed. will be uploaded soon.
>>>>
>>>>
>>>>>
>>>>> Igor
>>>>>
>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote:
>>>>>>
>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote:
>>>>>>> Hi
>>>>>>> So here is trivial patch -
>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and adding
>>>>>>> main/othervm/bootclasspath
>>>>>>> where this needed
>>>>>>>
>>>>>>> Also, some tests are modified as
>>>>>>> - "-Xbootclasspath/a:.",
>>>>>>> + "-Xbootclasspath/a:" + System.getProperty("test.classes"),
>>>>>>>
>>>>>>> Thanks.
>>>>>> webrev: http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8011397
>>>>>> Thanks.
>>>>>>
>>>>>>>
>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote:
>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote:
>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime and gc lists.
>>>>>>>>>
>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote:
>>>>>>>>>> Andrey,
>>>>>>>>>>
>>>>>>>>>> I've CC'ed compiler and runtime mailing list, because you're
>>>>>>>>>> changes
>>>>>>>>>> affect test for other components as too.
>>>>>>>>>>
>>>>>>>>>> I don't like your solution (but I'm not a reviewer, so treat my
>>>>>>>>>> words
>>>>>>>>>> just as suggestion),
>>>>>>>>>> because we'll have to write more meta information for each test
>>>>>>>>>> and it
>>>>>>>>>> is very easy to
>>>>>>>>>> forget to install WhiteBoxPermission if you don't test your test
>>>>>>>>>> with
>>>>>>>>>> some security manager.
>>>>>>>>>>
>>>>>>>>>> From my point of view, it will be better to extend
>>>>>>>>>> ClassFileInstaller
>>>>>>>>>>
>>>>>>>>>> so it will copy not only
>>>>>>>>>> a class whose name was passed as an arguments, but also all
>>>>>>>>>> inner
>>>>>>>>>> classes of that class.
>>>>>>>>>> And if someone want copy only specified class without inner
>>>>>>>>>> classes,
>>>>>>>>>> then some option
>>>>>>>>>> could be added to ClassFileInstaller to force such behaviour.
>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller
>>>>>>>> altogether?
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117
>>>>>>>>
>>>>>>>> The reason for its existence is that the WhiteBox class needs
>>>>>>>> to be
>>>>>>>> on the
>>>>>>>> boot class path.
>>>>>>>> If we can live with having all the test's classes on the boot
>>>>>>>> class
>>>>>>>> path then
>>>>>>>> we could use the /bootclasspath option in jtreg as stated in
>>>>>>>> the RFE.
>>>>>>>>
>>>>>>>> /Mikael
>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Filipp.
>>>>>>>>>>
>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote:
>>>>>>>>>>> Hi!
>>>>>>>>>>> Suggesting patch with fixes for
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397
>>>>>>>>>>>
>>>>>>>>>>> webrev:
>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397.tgz
>>>>>>>>>>>
>>>>>>>>>>> patch:
>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397.WhiteBoxPer
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> mission
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>
>>>>>>
>>>>
>>>
>
From tdaitx at br.ibm.com Wed Jun 25 19:52:03 2014
From: tdaitx at br.ibm.com (Tiago =?ISO-8859-1?Q?St=FCrmer?= Daitx)
Date: Wed, 25 Jun 2014 16:52:03 -0300
Subject: [patch] fixing the ppc64el hotspot build in 8u20-b16
In-Reply-To: <5390809A.5050800@ubuntu.com>
References: <5390809A.5050800@ubuntu.com>
Message-ID: <1403725923.3862.339.camel@ocdc.br.ibm.com>
Cross-posting to hotspot-dev.
On Thu, 2014-06-05 at 16:37 +0200, Matthias Klose wrote:
> Hi,
>
> the ppc64el hotspot seems to be merged in 8u20-b16. However I got some build
> failures building on ppc64el, fixed with the attached patch. Are you aware of
> any other patches needed for the port?
>
> Thanks, Matthias
# Missing bits for the PPC ELF v2 ABI
--- a/hotspot/src/cpu/ppc/vm/interp_masm_ppc_64.cpp
+++ b/hotspot/src/cpu/ppc/vm/interp_masm_ppc_64.cpp
@@ -119,9 +119,15 @@
// Call the Interpreter::remove_activation_preserving_args_entry()
// func to get the address of the same-named entrypoint in the
// generated interpreter code.
+#if !defined(ABI_ELFv2)
call_c(CAST_FROM_FN_PTR(FunctionDescriptor*,
Interpreter::remove_activation_preserving_args_entry),
relocInfo::none);
+#else
+ call_c(CAST_FROM_FN_PTR(address,
+
Interpreter::remove_activation_preserving_args_entry),
+ relocInfo::none);
+#endif
// Jump to Interpreter::_remove_activation_preserving_args_entry.
mtctr(R3_RET);
--- a/hotspot/src/cpu/ppc/vm/templateInterpreter_ppc.cpp
+++ b/hotspot/src/cpu/ppc/vm/templateInterpreter_ppc.cpp
@@ -1019,8 +1019,13 @@
// native result across the call. No oop is present.
__ mr(R3_ARG1, R16_thread);
+#if !defined(ABI_ELFv2)
__ call_c(CAST_FROM_FN_PTR(FunctionDescriptor*,
JavaThread::check_special_condition_for_native_trans),
relocInfo::none);
+#else
+ __ call_c(CAST_FROM_FN_PTR(address,
JavaThread::check_special_condition_for_native_trans),
+ relocInfo::none);
+#endif
__ bind(sync_check_done);
--
Tiago St?rmer Daitx
Linux Technology Center [LTC|IBM]
tdaitx at br.ibm.com
From igor.veresov at oracle.com Wed Jun 25 21:53:33 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 25 Jun 2014 14:53:33 -0700
Subject: RFR: 8047326: Add a version of CompiledIC_at that doesn't create
a new RelocIterator
In-Reply-To: <53A98296.5090604@oracle.com>
References: <53A2DB59.9050605@oracle.com> <53A3038C.9020004@oracle.com>
<53A98296.5090604@oracle.com>
Message-ID: <CE5B1BCB-70F2-4224-8821-C4D23F18DA6A@oracle.com>
Looks good. Very nice improvement.
igor
ps. We should probably get something like a BOT for the CodeCache. The reason RelocIterator's constructor is so bad is that it actually iterates over the whole code cache to find the blob that contains the start address. Ugh..
On Jun 24, 2014, at 6:52 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> Hi all,
>
> Could someone from the Compiler team take a look and review/comment on this patch?
>
> thanks,
> StefanK
>
> On 2014-06-19 17:36, Stefan Karlsson wrote:
>> This was meant for the hotspot-dev list. BCC:ing hotspot-gc-dev.
>>
>> On 2014-06-19 14:45, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> I have a patch that we have been using in the G1 Class Unloading project to lower the remark times. This changes Compiler code, so I would like to get feedback from the Compiler team.
>>>
>>> http://cr.openjdk.java.net/~stefank/8047362/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8047362
>>>
>>> The patch builds upon the patch in:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014358.html
>>>
>>>
>>> Summary from the bug report:
>>> ---
>>> Creation of RelocIterators show up high in profiles of the remark phase, in the G1 Class Unloading project.
>>>
>>> There's a pattern in the nmethod/codecache code to create a RelocIterator and then materialize a CompiledIC:
>>>
>>> RelocIterator iter(this, low_boundary);
>>> while(iter.next()) {
>>> if (iter.type() == relocInfo::virtual_call_type) {
>>> CompiledIC *ic = CompiledIC_at(iter.reloc());
>>>
>>> CompiledIC_at is implemented as:
>>> new CompiledIC(call_site->code(), nativeCall_at(call_site->addr()));
>>>
>>> And one of the first thing CompiledIC::CompiledIC(const nmethod* nm, NativeCall* call) does is to create a new RelocIterator:
>>> ...
>>> address ic_call = call->instruction_address();
>>> ...
>>> RelocIterator iter(nm, ic_call, ic_call+1);
>>> bool ret = iter.next();
>>> assert(ret == true, "relocInfo must exist at this address");
>>> assert(iter.addr() == ic_call, "must find ic_call");
>>>
>>> I would like to propose that we pass down the RelocIterator that we already have, instead of creating a new.
>>> ---
>>>
>>>
>>> I've previously received feedback that this seems like reasonable thing to do, but that the parameter to the new CompileIC_at should take a const RelocIterator* instead of RelocIterator*. I couldn't do that without changing a significant amount of Compiler code, so I have left it out for now. Any opinions on how to handle that?
>>>
>>>
>>> To give an idea of the performance difference, I temporarily added the following code:
>>> void CodeCache::iterate_through_CIs(int style) {
>>> int count;
>>> FOR_ALL_ALIVE_NMETHODS(nm) {
>>> RelocIterator iter(nm);
>>> while(iter.next()) {
>>> if (iter.type() == relocInfo::virtual_call_type ||
>>> iter.type() == relocInfo::opt_virtual_call_type) {
>>> if (style > 0) {
>>> CompiledIC *ic = style == 1 ? CompiledIC_at(&iter) : CompiledIC_at(iter.reloc());
>>> if (ic->ic_destination() == (address)0xdeadb000) {
>>> gclog_or_tty->print_cr("ShouldNotReachHere");
>>> }
>>> }
>>> }
>>> }
>>> }
>>> }
>>>
>>> and then measured how long time it took to execute iterate_through_CIs(style) 1000 times with style == {0, 1, 2}.
>>>
>>> The results are:
>>> iterate_through_CIs(0): 1.210833 s // No CompiledICs created
>>> iterate_through_CIs(1): 1.976557 s // New style
>>> iterate_through_CIs(2): 9.924209 s // Old style
>>>
>>>
>>> Testing:
>>> A similar version has been used and thoroughly been tested together with the other G1 Class Unloading changes. This exact version has so far only been tested with Kitchensink and SpecJVM2008 compiler.compiler. What test lists would be appropriate to test this with?
>>>
>>>
>>> thanks,
>>> StefanK
>>>
>>
>
From alejandro.murillo at oracle.com Thu Jun 26 00:17:04 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 25 Jun 2014 18:17:04 -0600
Subject: Repo for hotspot changes destined for 8u20 & 8u40
Message-ID: <53AB6680.8050309@oracle.com>
(1) 8u20:
Going forward, Hotspot changes destined/approved for 8u20
should be pushed to [1], unless the change should NOT be pushed
to 8u40 for any reason, in which case please contact me before pushing it
(I expect all fixes going to 8u20 being also required in 8u40).
Changes pushed to [1] and approved for 8u20, will be taken to the
8u20 stabilization forest [2] after PIT (or via PIT waiver).
(2) 8u40:
jdk8u/hs-dev/hotspot ([1]) has been associated with 8u40,
so it is now ready to receive Hotspot changes destined for 8u40.
As usual for update releases, you do not need to request approval to
push, just request for reviews in the hotspot alias. I will request the
approval to push when taking the changes to the respective master
repos after PIT
let me know if something is not clear
Thanks
[1] http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot
[2] http://hg.openjdk.java.net/jdk8u/jdk8u20/hotspot
--
Alejandro
From tdaitx at br.ibm.com Wed Jun 25 18:18:01 2014
From: tdaitx at br.ibm.com (Tiago =?ISO-8859-1?Q?St=FCrmer?= Daitx)
Date: Wed, 25 Jun 2014 15:18:01 -0300
Subject: OpenJDK9 build failure
In-Reply-To: <1403103138.3862.274.camel@ocdc.br.ibm.com>
References: <1403103138.3862.274.camel@ocdc.br.ibm.com>
Message-ID: <1403720281.3862.336.camel@ocdc.br.ibm.com>
Adding hotspot-dev to the thread.
On Wed, 2014-06-18 at 11:52 -0300, Tiago Sturmer Daitx wrote:
tl;dr I have had problems building JDK9 due to -Werror=format flag on gcc/g++ 4.8.2
and also due to hotspot/agent/src/os/linux/libproc.h including
linux/ptrace.h instead of sys/ptrace.h
I have been trying to build JDK9 from
http://hg.openjdk.java.net/jdk9/dev (or /hs-comp or /jdk9) and JDK8u
from http://hg.openjdk.java.net/jdk8u/jdk8u/
First, I'm seeing the following on JDK9 only:
/usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
-I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/prims
-I/home/tdaitx/jdk9-dev/hotspot/sr
c/share/vm -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/precompiled
-I/home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm
-I/home/tdaitx/jdk9-dev/hot
spot/src/os_cpu/linux_ppc/vm
-I/home/tdaitx/jdk9-dev/hotspot/src/os/linux/vm
-I/home/tdaitx/jdk9-dev/hotspot/src/os/posix/vm -I../generated -D
HOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"tdaitx\""
-DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
-DTARGET_
OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
-DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
-DTARGET_COMPILER_
gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new
-fvisibility=hidden -m64 -DCC_INTERP -pipe -fno-strict-aliasing -fno
-omit-frame-pointer -O3 -g -D_LP64=1 -mminimal-toc -mcpu=powerpc64
-mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple
-mno-string
-Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
-Wunused-value -Wformat=2 -Wno-strict-aliasing -Werror
-DDTRACE_ENABLED -c
-MMD -MP -MF ../generated/dependencies/bytecodes.o.d -fpch-deps -o
bytecodes.o /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecod
es.cpp
Compiling /home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm/bytecodes_ppc.cpp
rm -f bytecodes_ppc.o
In file included
from /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:31:0:
/home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?:
/home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95:17: error: format ?%lx? expects argument of type ?long unsigned int?, but argument 5 has type ?DataLayout*? [-Werror=format=]
);
Pasted at http://fpaste.org/110642/30430021/ (and there are many many lines with
similar errors until the build is aborted).
After ignoring the error ('CFLAGS="-Wno-error=format" make' or editing
make/linux/makefiles/gcc.make to remove "-Werror=format"), I get the
following on JDK9:
Making SA debugger back-end...
/usr/bin/gcc -Dppc64 -D_GNU_SOURCE \
-D_FILE_OFFSET_BITS=64 \
-g -m64 -shared -fPIC \
-I/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux
\
-I../generated \
-I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include
\
-I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include/linux
\
\
/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/salibelf.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/symtab.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_core.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c /home/tdaitx/jdk9-dev/hotspot/agent/src/share/native/sadis.c \
-Xlinker
--version-script=/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/mapfile -Wl,--hash-style=both \
\
-Wno-strict-aliasing -Werror
\
-o libsaproc.so
\
-lthread_db
In file included
from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0,
from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30,
from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33:
/usr/include/linux/ptrace.h:58:8: error: redefinition of ?struct
ptrace_peeksiginfo_args?
struct ptrace_peeksiginfo_args {
^
In file included
from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0:
/usr/include/sys/ptrace.h:161:8: note: originally defined here
struct ptrace_peeksiginfo_args
Pasted at http://fpaste.org/110640/42657140/
For JDK8 see: http://fpaste.org/110638/40304229/
I see that both sys/ptrace.h and linux/ptrace.h have been included:
$ grep -r ptrace.h hotspot/
hotspot/agent/src/os/linux/ps_proc.c:#include <sys/ptrace.h>
hotspot/agent/src/os/linux/libproc.h:#include <linux/ptrace.h>
Usually linux/ptrace.h is used by glibc to do syscall, wile sys/ptrace.h
is used by app code to do library calls (thanks Maynard for the info).
After editing hotspot/agent/src/os/linux/libproc.h to use sys/ptrace.h
I'm able to build both JDK8 & JDK9.
Some settings:
JDK8 configure:
$ ./configure \
--with-boot-jdk=/home/tdaitx/icedtea7/openjdk.build/j2sdk-image/ \
--with-jvm-variants=server --with-jvm-interpreter=cpp \
--with-extra-cflags=-Wno-strict-aliasing
JDK9 configure is similar but I point it to a JDK8 build.
Make for JDK8 and JDK9:
$ make JOBS=8 LOG=debug
$ /usr/bin/gcc -v # g++ is the same, except for COLLECT_GCC
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.2/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c
++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/cloog-install --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
$ cat /etc/redhat-release
Fedora release 20 (Heisenbug)
$ rpm -qf /usr/include/linux/ptrace.h
kernel-headers-3.14.5-200.fc20.ppc64p7
$ rpm -qf /usr/include/sys/ptrace.h
glibc-headers-2.18-12.fc20.ppc64p7
Let me know if you need any additional info.
Regards,
Tiago
--
Tiago St?rmer Daitx
Linux Technology Center [LTC|IBM]
tdaitx at br.ibm.com
From david.holmes at oracle.com Thu Jun 26 02:33:05 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Jun 2014 12:33:05 +1000
Subject: OpenJDK9 build failure
In-Reply-To: <1403720281.3862.336.camel@ocdc.br.ibm.com>
References: <1403103138.3862.274.camel@ocdc.br.ibm.com>
<1403720281.3862.336.camel@ocdc.br.ibm.com>
Message-ID: <53AB8661.3080606@oracle.com>
Hi,
The ptrace issue has been fixed:
https://bugs.openjdk.java.net/browse/JDK-8046408
but it is in the hs-gc forest and not yet propagated up to jdk9/dev.
I don't think the format error has been reported yet.
David
On 26/06/2014 4:18 AM, Tiago St?rmer Daitx wrote:
> Adding hotspot-dev to the thread.
>
> On Wed, 2014-06-18 at 11:52 -0300, Tiago Sturmer Daitx wrote:
>
> tl;dr I have had problems building JDK9 due to -Werror=format flag on gcc/g++ 4.8.2
> and also due to hotspot/agent/src/os/linux/libproc.h including
> linux/ptrace.h instead of sys/ptrace.h
>
>
> I have been trying to build JDK9 from
> http://hg.openjdk.java.net/jdk9/dev (or /hs-comp or /jdk9) and JDK8u
> from http://hg.openjdk.java.net/jdk8u/jdk8u/
>
> First, I'm seeing the following on JDK9 only:
>
>
> /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
> -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/prims
> -I/home/tdaitx/jdk9-dev/hotspot/sr
> c/share/vm -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/precompiled
> -I/home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm
> -I/home/tdaitx/jdk9-dev/hot
> spot/src/os_cpu/linux_ppc/vm
> -I/home/tdaitx/jdk9-dev/hotspot/src/os/linux/vm
> -I/home/tdaitx/jdk9-dev/hotspot/src/os/posix/vm -I../generated -D
> HOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"tdaitx\""
> -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
> -DTARGET_
> OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
> -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
> -DTARGET_COMPILER_
> gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new
> -fvisibility=hidden -m64 -DCC_INTERP -pipe -fno-strict-aliasing -fno
> -omit-frame-pointer -O3 -g -D_LP64=1 -mminimal-toc -mcpu=powerpc64
> -mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple
> -mno-string
> -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
> -Wunused-value -Wformat=2 -Wno-strict-aliasing -Werror
> -DDTRACE_ENABLED -c
> -MMD -MP -MF ../generated/dependencies/bytecodes.o.d -fpch-deps -o
> bytecodes.o /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecod
> es.cpp
> Compiling /home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm/bytecodes_ppc.cpp
> rm -f bytecodes_ppc.o
> In file included
> from /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:31:0:
> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?:
> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95:17: error: format ?%lx? expects argument of type ?long unsigned int?, but argument 5 has type ?DataLayout*? [-Werror=format=]
> );
>
> Pasted at http://fpaste.org/110642/30430021/ (and there are many many lines with
> similar errors until the build is aborted).
>
> After ignoring the error ('CFLAGS="-Wno-error=format" make' or editing
> make/linux/makefiles/gcc.make to remove "-Werror=format"), I get the
> following on JDK9:
>
>
> Making SA debugger back-end...
> /usr/bin/gcc -Dppc64 -D_GNU_SOURCE \
> -D_FILE_OFFSET_BITS=64 \
> -g -m64 -shared -fPIC \
> -I/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux
> \
> -I../generated \
>
> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include
> \
>
> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include/linux
> \
>
> \
>
> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/salibelf.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/symtab.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_core.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c /home/tdaitx/jdk9-dev/hotspot/agent/src/share/native/sadis.c \
> -Xlinker
> --version-script=/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/mapfile -Wl,--hash-style=both \
> \
> -Wno-strict-aliasing -Werror
> \
> -o libsaproc.so
> \
> -lthread_db
> In file included
> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0,
>
> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30,
>
> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33:
> /usr/include/linux/ptrace.h:58:8: error: redefinition of ?struct
> ptrace_peeksiginfo_args?
> struct ptrace_peeksiginfo_args {
> ^
> In file included
> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0:
> /usr/include/sys/ptrace.h:161:8: note: originally defined here
> struct ptrace_peeksiginfo_args
>
>
> Pasted at http://fpaste.org/110640/42657140/
>
> For JDK8 see: http://fpaste.org/110638/40304229/
>
> I see that both sys/ptrace.h and linux/ptrace.h have been included:
>
> $ grep -r ptrace.h hotspot/
> hotspot/agent/src/os/linux/ps_proc.c:#include <sys/ptrace.h>
> hotspot/agent/src/os/linux/libproc.h:#include <linux/ptrace.h>
>
> Usually linux/ptrace.h is used by glibc to do syscall, wile sys/ptrace.h
> is used by app code to do library calls (thanks Maynard for the info).
>
> After editing hotspot/agent/src/os/linux/libproc.h to use sys/ptrace.h
> I'm able to build both JDK8 & JDK9.
>
> Some settings:
>
> JDK8 configure:
> $ ./configure \
> --with-boot-jdk=/home/tdaitx/icedtea7/openjdk.build/j2sdk-image/ \
> --with-jvm-variants=server --with-jvm-interpreter=cpp \
> --with-extra-cflags=-Wno-strict-aliasing
>
> JDK9 configure is similar but I point it to a JDK8 build.
>
> Make for JDK8 and JDK9:
> $ make JOBS=8 LOG=debug
>
>
>
> $ /usr/bin/gcc -v # g++ is the same, except for COLLECT_GCC
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.2/lto-wrapper
> Target: ppc64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info
> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
> --enable-shared --enable-threads=posix --enable-checking=release
> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
> --enable-gnu-unique-object --enable-linker-build-id
> --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c
> ++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array
> --enable-java-awt=gtk --disable-dssi
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
> --enable-libgcj-multifile --enable-java-maintainer-mode
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> --disable-libjava-multilib
> --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/cloog-install --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
> Thread model: posix
> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
>
> $ cat /etc/redhat-release
> Fedora release 20 (Heisenbug)
>
> $ rpm -qf /usr/include/linux/ptrace.h
> kernel-headers-3.14.5-200.fc20.ppc64p7
>
> $ rpm -qf /usr/include/sys/ptrace.h
> glibc-headers-2.18-12.fc20.ppc64p7
>
> Let me know if you need any additional info.
>
> Regards,
> Tiago
>
From tdaitx at br.ibm.com Thu Jun 26 04:43:13 2014
From: tdaitx at br.ibm.com (Tiago =?ISO-8859-1?Q?St=FCrmer?= Daitx)
Date: Thu, 26 Jun 2014 01:43:13 -0300
Subject: OpenJDK9 build failure
In-Reply-To: <53AB8661.3080606@oracle.com>
References: <1403103138.3862.274.camel@ocdc.br.ibm.com>
<1403720281.3862.336.camel@ocdc.br.ibm.com>
<53AB8661.3080606@oracle.com>
Message-ID: <1403757793.3862.344.camel@ocdc.br.ibm.com>
On Thu, 2014-06-26 at 12:33 +1000, David Holmes wrote:
> Hi,
>
> The ptrace issue has been fixed:
>
> https://bugs.openjdk.java.net/browse/JDK-8046408
>
> but it is in the hs-gc forest and not yet propagated up to jdk9/dev.
>
> I don't think the format error has been reported yet.
David,
thanks for the pointer on the ptrace fix. I'm sorry that I didn't check
JBS beforehand.
I don't have an account in JBS, thus I'm unable to create a bug report
for the format error. What would be the right approach here?
Regards,
Tiago
>
> David
>
> On 26/06/2014 4:18 AM, Tiago St?rmer Daitx wrote:
> > Adding hotspot-dev to the thread.
> >
> > On Wed, 2014-06-18 at 11:52 -0300, Tiago Sturmer Daitx wrote:
> >
> > tl;dr I have had problems building JDK9 due to -Werror=format flag on gcc/g++ 4.8.2
> > and also due to hotspot/agent/src/os/linux/libproc.h including
> > linux/ptrace.h instead of sys/ptrace.h
> >
> >
> > I have been trying to build JDK9 from
> > http://hg.openjdk.java.net/jdk9/dev (or /hs-comp or /jdk9) and JDK8u
> > from http://hg.openjdk.java.net/jdk8u/jdk8u/
> >
> > First, I'm seeing the following on JDK9 only:
> >
> >
> > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
> > -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/prims
> > -I/home/tdaitx/jdk9-dev/hotspot/sr
> > c/share/vm -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/precompiled
> > -I/home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm
> > -I/home/tdaitx/jdk9-dev/hot
> > spot/src/os_cpu/linux_ppc/vm
> > -I/home/tdaitx/jdk9-dev/hotspot/src/os/linux/vm
> > -I/home/tdaitx/jdk9-dev/hotspot/src/os/posix/vm -I../generated -D
> > HOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"tdaitx\""
> > -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
> > -DTARGET_
> > OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
> > -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
> > -DTARGET_COMPILER_
> > gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new
> > -fvisibility=hidden -m64 -DCC_INTERP -pipe -fno-strict-aliasing -fno
> > -omit-frame-pointer -O3 -g -D_LP64=1 -mminimal-toc -mcpu=powerpc64
> > -mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple
> > -mno-string
> > -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
> > -Wunused-value -Wformat=2 -Wno-strict-aliasing -Werror
> > -DDTRACE_ENABLED -c
> > -MMD -MP -MF ../generated/dependencies/bytecodes.o.d -fpch-deps -o
> > bytecodes.o /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecod
> > es.cpp
> > Compiling /home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm/bytecodes_ppc.cpp
> > rm -f bytecodes_ppc.o
> > In file included
> > from /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:31:0:
> > /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?:
> > /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95:17: error: format ?%lx? expects argument of type ?long unsigned int?, but argument 5 has type ?DataLayout*? [-Werror=format=]
> > );
> >
> > Pasted at http://fpaste.org/110642/30430021/ (and there are many many lines with
> > similar errors until the build is aborted).
> >
> > After ignoring the error ('CFLAGS="-Wno-error=format" make' or editing
> > make/linux/makefiles/gcc.make to remove "-Werror=format"), I get the
> > following on JDK9:
> >
> >
> > Making SA debugger back-end...
> > /usr/bin/gcc -Dppc64 -D_GNU_SOURCE \
> > -D_FILE_OFFSET_BITS=64 \
> > -g -m64 -shared -fPIC \
> > -I/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux
> > \
> > -I../generated \
> >
> > -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include
> > \
> >
> > -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include/linux
> > \
> >
> > \
> >
> > /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/salibelf.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/symtab.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_core.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c /home/tdaitx/jdk9-dev/hotspot/agent/src/share/native/sadis.c \
> > -Xlinker
> > --version-script=/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/mapfile -Wl,--hash-style=both \
> > \
> > -Wno-strict-aliasing -Werror
> > \
> > -o libsaproc.so
> > \
> > -lthread_db
> > In file included
> > from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0,
> >
> > from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30,
> >
> > from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33:
> > /usr/include/linux/ptrace.h:58:8: error: redefinition of ?struct
> > ptrace_peeksiginfo_args?
> > struct ptrace_peeksiginfo_args {
> > ^
> > In file included
> > from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0:
> > /usr/include/sys/ptrace.h:161:8: note: originally defined here
> > struct ptrace_peeksiginfo_args
> >
> >
> > Pasted at http://fpaste.org/110640/42657140/
> >
> > For JDK8 see: http://fpaste.org/110638/40304229/
> >
> > I see that both sys/ptrace.h and linux/ptrace.h have been included:
> >
> > $ grep -r ptrace.h hotspot/
> > hotspot/agent/src/os/linux/ps_proc.c:#include <sys/ptrace.h>
> > hotspot/agent/src/os/linux/libproc.h:#include <linux/ptrace.h>
> >
> > Usually linux/ptrace.h is used by glibc to do syscall, wile sys/ptrace.h
> > is used by app code to do library calls (thanks Maynard for the info).
> >
> > After editing hotspot/agent/src/os/linux/libproc.h to use sys/ptrace.h
> > I'm able to build both JDK8 & JDK9.
> >
> > Some settings:
> >
> > JDK8 configure:
> > $ ./configure \
> > --with-boot-jdk=/home/tdaitx/icedtea7/openjdk.build/j2sdk-image/ \
> > --with-jvm-variants=server --with-jvm-interpreter=cpp \
> > --with-extra-cflags=-Wno-strict-aliasing
> >
> > JDK9 configure is similar but I point it to a JDK8 build.
> >
> > Make for JDK8 and JDK9:
> > $ make JOBS=8 LOG=debug
> >
> >
> >
> > $ /usr/bin/gcc -v # g++ is the same, except for COLLECT_GCC
> > Using built-in specs.
> > COLLECT_GCC=/usr/bin/gcc
> > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.2/lto-wrapper
> > Target: ppc64-redhat-linux
> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > --infodir=/usr/share/info
> > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
> > --enable-shared --enable-threads=posix --enable-checking=release
> > --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
> > --enable-gnu-unique-object --enable-linker-build-id
> > --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c
> > ++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array
> > --enable-java-awt=gtk --disable-dssi
> > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
> > --enable-libgcj-multifile --enable-java-maintainer-mode
> > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> > --disable-libjava-multilib
> > --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/cloog-install --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
> > Thread model: posix
> > gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
> >
> > $ cat /etc/redhat-release
> > Fedora release 20 (Heisenbug)
> >
> > $ rpm -qf /usr/include/linux/ptrace.h
> > kernel-headers-3.14.5-200.fc20.ppc64p7
> >
> > $ rpm -qf /usr/include/sys/ptrace.h
> > glibc-headers-2.18-12.fc20.ppc64p7
> >
> > Let me know if you need any additional info.
> >
> > Regards,
> > Tiago
> >
>
--
Tiago St?rmer Daitx
Linux Technology Center [LTC|IBM]
tdaitx at br.ibm.com
From david.holmes at oracle.com Thu Jun 26 06:43:32 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Jun 2014 16:43:32 +1000
Subject: OpenJDK9 build failure
In-Reply-To: <1403757793.3862.344.camel@ocdc.br.ibm.com>
References: <1403103138.3862.274.camel@ocdc.br.ibm.com>
<1403720281.3862.336.camel@ocdc.br.ibm.com>
<53AB8661.3080606@oracle.com>
<1403757793.3862.344.camel@ocdc.br.ibm.com>
Message-ID: <53ABC114.4080400@oracle.com>
On 26/06/2014 2:43 PM, Tiago St?rmer Daitx wrote:
> On Thu, 2014-06-26 at 12:33 +1000, David Holmes wrote:
>> Hi,
>>
>> The ptrace issue has been fixed:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8046408
>>
>> but it is in the hs-gc forest and not yet propagated up to jdk9/dev.
>>
>> I don't think the format error has been reported yet.
>
> David,
>
> thanks for the pointer on the ptrace fix. I'm sorry that I didn't check
> JBS beforehand.
>
> I don't have an account in JBS, thus I'm unable to create a bug report
> for the format error. What would be the right approach here?
I have created:
https://bugs.openjdk.java.net/browse/JDK-8048169
"Incorrect format specifier used in
src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95"
David
-----
> Regards,
> Tiago
>
>>
>> David
>>
>> On 26/06/2014 4:18 AM, Tiago St?rmer Daitx wrote:
>>> Adding hotspot-dev to the thread.
>>>
>>> On Wed, 2014-06-18 at 11:52 -0300, Tiago Sturmer Daitx wrote:
>>>
>>> tl;dr I have had problems building JDK9 due to -Werror=format flag on gcc/g++ 4.8.2
>>> and also due to hotspot/agent/src/os/linux/libproc.h including
>>> linux/ptrace.h instead of sys/ptrace.h
>>>
>>>
>>> I have been trying to build JDK9 from
>>> http://hg.openjdk.java.net/jdk9/dev (or /hs-comp or /jdk9) and JDK8u
>>> from http://hg.openjdk.java.net/jdk8u/jdk8u/
>>>
>>> First, I'm seeing the following on JDK9 only:
>>>
>>>
>>> /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
>>> -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/prims
>>> -I/home/tdaitx/jdk9-dev/hotspot/sr
>>> c/share/vm -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/precompiled
>>> -I/home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm
>>> -I/home/tdaitx/jdk9-dev/hot
>>> spot/src/os_cpu/linux_ppc/vm
>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/linux/vm
>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/posix/vm -I../generated -D
>>> HOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"tdaitx\""
>>> -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
>>> -DTARGET_
>>> OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
>>> -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
>>> -DTARGET_COMPILER_
>>> gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new
>>> -fvisibility=hidden -m64 -DCC_INTERP -pipe -fno-strict-aliasing -fno
>>> -omit-frame-pointer -O3 -g -D_LP64=1 -mminimal-toc -mcpu=powerpc64
>>> -mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple
>>> -mno-string
>>> -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
>>> -Wunused-value -Wformat=2 -Wno-strict-aliasing -Werror
>>> -DDTRACE_ENABLED -c
>>> -MMD -MP -MF ../generated/dependencies/bytecodes.o.d -fpch-deps -o
>>> bytecodes.o /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecod
>>> es.cpp
>>> Compiling /home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm/bytecodes_ppc.cpp
>>> rm -f bytecodes_ppc.o
>>> In file included
>>> from /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:31:0:
>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?:
>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95:17: error: format ?%lx? expects argument of type ?long unsigned int?, but argument 5 has type ?DataLayout*? [-Werror=format=]
>>> );
>>>
>>> Pasted at http://fpaste.org/110642/30430021/ (and there are many many lines with
>>> similar errors until the build is aborted).
>>>
>>> After ignoring the error ('CFLAGS="-Wno-error=format" make' or editing
>>> make/linux/makefiles/gcc.make to remove "-Werror=format"), I get the
>>> following on JDK9:
>>>
>>>
>>> Making SA debugger back-end...
>>> /usr/bin/gcc -Dppc64 -D_GNU_SOURCE \
>>> -D_FILE_OFFSET_BITS=64 \
>>> -g -m64 -shared -fPIC \
>>> -I/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux
>>> \
>>> -I../generated \
>>>
>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include
>>> \
>>>
>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include/linux
>>> \
>>>
>>> \
>>>
>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/salibelf.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/symtab.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_core.c /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c /home/tdaitx/jdk9-dev/hotspot/agent/src/share/native/sadis.c \
>>> -Xlinker
>>> --version-script=/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/mapfile -Wl,--hash-style=both \
>>> \
>>> -Wno-strict-aliasing -Werror
>>> \
>>> -o libsaproc.so
>>> \
>>> -lthread_db
>>> In file included
>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0,
>>>
>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30,
>>>
>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33:
>>> /usr/include/linux/ptrace.h:58:8: error: redefinition of ?struct
>>> ptrace_peeksiginfo_args?
>>> struct ptrace_peeksiginfo_args {
>>> ^
>>> In file included
>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0:
>>> /usr/include/sys/ptrace.h:161:8: note: originally defined here
>>> struct ptrace_peeksiginfo_args
>>>
>>>
>>> Pasted at http://fpaste.org/110640/42657140/
>>>
>>> For JDK8 see: http://fpaste.org/110638/40304229/
>>>
>>> I see that both sys/ptrace.h and linux/ptrace.h have been included:
>>>
>>> $ grep -r ptrace.h hotspot/
>>> hotspot/agent/src/os/linux/ps_proc.c:#include <sys/ptrace.h>
>>> hotspot/agent/src/os/linux/libproc.h:#include <linux/ptrace.h>
>>>
>>> Usually linux/ptrace.h is used by glibc to do syscall, wile sys/ptrace.h
>>> is used by app code to do library calls (thanks Maynard for the info).
>>>
>>> After editing hotspot/agent/src/os/linux/libproc.h to use sys/ptrace.h
>>> I'm able to build both JDK8 & JDK9.
>>>
>>> Some settings:
>>>
>>> JDK8 configure:
>>> $ ./configure \
>>> --with-boot-jdk=/home/tdaitx/icedtea7/openjdk.build/j2sdk-image/ \
>>> --with-jvm-variants=server --with-jvm-interpreter=cpp \
>>> --with-extra-cflags=-Wno-strict-aliasing
>>>
>>> JDK9 configure is similar but I point it to a JDK8 build.
>>>
>>> Make for JDK8 and JDK9:
>>> $ make JOBS=8 LOG=debug
>>>
>>>
>>>
>>> $ /usr/bin/gcc -v # g++ is the same, except for COLLECT_GCC
>>> Using built-in specs.
>>> COLLECT_GCC=/usr/bin/gcc
>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.2/lto-wrapper
>>> Target: ppc64-redhat-linux
>>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>>> --infodir=/usr/share/info
>>> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
>>> --enable-shared --enable-threads=posix --enable-checking=release
>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
>>> --enable-gnu-unique-object --enable-linker-build-id
>>> --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c
>>> ++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array
>>> --enable-java-awt=gtk --disable-dssi
>>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
>>> --enable-libgcj-multifile --enable-java-maintainer-mode
>>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
>>> --disable-libjava-multilib
>>> --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/cloog-install --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
>>> Thread model: posix
>>> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
>>>
>>> $ cat /etc/redhat-release
>>> Fedora release 20 (Heisenbug)
>>>
>>> $ rpm -qf /usr/include/linux/ptrace.h
>>> kernel-headers-3.14.5-200.fc20.ppc64p7
>>>
>>> $ rpm -qf /usr/include/sys/ptrace.h
>>> glibc-headers-2.18-12.fc20.ppc64p7
>>>
>>> Let me know if you need any additional info.
>>>
>>> Regards,
>>> Tiago
>>>
>>
>
>
From volker.simonis at gmail.com Thu Jun 26 07:30:45 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Jun 2014 09:30:45 +0200
Subject: OpenJDK9 build failure
In-Reply-To: <53ABC114.4080400@oracle.com>
References: <1403103138.3862.274.camel@ocdc.br.ibm.com>
<1403720281.3862.336.camel@ocdc.br.ibm.com>
<53AB8661.3080606@oracle.com>
<1403757793.3862.344.camel@ocdc.br.ibm.com>
<53ABC114.4080400@oracle.com>
Message-ID: <CA+3eh10jSeHrRs5cK_Pwk7uiyzyKtur=7Q8Hmz3T1DRr2E=EUw@mail.gmail.com>
Hi David, Tiago,
sorry for the daly, but I was on leave during the last two weeks.
I already have a patch for the 'format specifier issue' and will post
a webrev later today.
@David: thanks for creating the bug!
Regards,
Volker
On Thu, Jun 26, 2014 at 8:43 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 26/06/2014 2:43 PM, Tiago St?rmer Daitx wrote:
>>
>> On Thu, 2014-06-26 at 12:33 +1000, David Holmes wrote:
>>>
>>> Hi,
>>>
>>> The ptrace issue has been fixed:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8046408
>>>
>>> but it is in the hs-gc forest and not yet propagated up to jdk9/dev.
>>>
>>> I don't think the format error has been reported yet.
>>
>>
>> David,
>>
>> thanks for the pointer on the ptrace fix. I'm sorry that I didn't check
>> JBS beforehand.
>>
>> I don't have an account in JBS, thus I'm unable to create a bug report
>> for the format error. What would be the right approach here?
>
>
> I have created:
>
> https://bugs.openjdk.java.net/browse/JDK-8048169
>
> "Incorrect format specifier used in
> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95"
>
> David
> -----
>
>
>> Regards,
>> Tiago
>>
>>>
>>> David
>>>
>>> On 26/06/2014 4:18 AM, Tiago St?rmer Daitx wrote:
>>>>
>>>> Adding hotspot-dev to the thread.
>>>>
>>>> On Wed, 2014-06-18 at 11:52 -0300, Tiago Sturmer Daitx wrote:
>>>>
>>>> tl;dr I have had problems building JDK9 due to -Werror=format flag on
>>>> gcc/g++ 4.8.2
>>>> and also due to hotspot/agent/src/os/linux/libproc.h including
>>>> linux/ptrace.h instead of sys/ptrace.h
>>>>
>>>>
>>>> I have been trying to build JDK9 from
>>>> http://hg.openjdk.java.net/jdk9/dev (or /hs-comp or /jdk9) and JDK8u
>>>> from http://hg.openjdk.java.net/jdk8u/jdk8u/
>>>>
>>>> First, I'm seeing the following on JDK9 only:
>>>>
>>>>
>>>> /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/prims
>>>> -I/home/tdaitx/jdk9-dev/hotspot/sr
>>>> c/share/vm -I/home/tdaitx/jdk9-dev/hotspot/src/share/vm/precompiled
>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm
>>>> -I/home/tdaitx/jdk9-dev/hot
>>>> spot/src/os_cpu/linux_ppc/vm
>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/linux/vm
>>>> -I/home/tdaitx/jdk9-dev/hotspot/src/os/posix/vm -I../generated -D
>>>> HOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"tdaitx\""
>>>> -DHOTSPOT_LIB_ARCH=\"ppc64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
>>>> -DTARGET_
>>>> OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
>>>> -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
>>>> -DTARGET_COMPILER_
>>>> gcc -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new
>>>> -fvisibility=hidden -m64 -DCC_INTERP -pipe -fno-strict-aliasing -fno
>>>> -omit-frame-pointer -O3 -g -D_LP64=1 -mminimal-toc -mcpu=powerpc64
>>>> -mtune=power5 -minsert-sched-nops=regroup_exact -mno-multiple
>>>> -mno-string
>>>> -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
>>>> -Wunused-value -Wformat=2 -Wno-strict-aliasing -Werror
>>>> -DDTRACE_ENABLED -c
>>>> -MMD -MP -MF ../generated/dependencies/bytecodes.o.d -fpch-deps -o
>>>> bytecodes.o
>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecod
>>>> es.cpp
>>>> Compiling /home/tdaitx/jdk9-dev/hotspot/src/cpu/ppc/vm/bytecodes_ppc.cpp
>>>> rm -f bytecodes_ppc.o
>>>> In file included
>>>> from
>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:31:0:
>>>>
>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:
>>>> In static member function ?static void
>>>> BytecodeInterpreter::run(interpreterState)?:
>>>>
>>>> /home/tdaitx/jdk9-dev/hotspot/src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp:95:17:
>>>> error: format ?%lx? expects argument of type ?long unsigned int?, but
>>>> argument 5 has type ?DataLayout*? [-Werror=format=]
>>>> );
>>>>
>>>> Pasted at http://fpaste.org/110642/30430021/ (and there are many many
>>>> lines with
>>>> similar errors until the build is aborted).
>>>>
>>>> After ignoring the error ('CFLAGS="-Wno-error=format" make' or editing
>>>> make/linux/makefiles/gcc.make to remove "-Werror=format"), I get the
>>>> following on JDK9:
>>>>
>>>>
>>>> Making SA debugger back-end...
>>>> /usr/bin/gcc -Dppc64 -D_GNU_SOURCE \
>>>> -D_FILE_OFFSET_BITS=64 \
>>>> -g -m64 -shared -fPIC \
>>>> -I/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux
>>>> \
>>>> -I../generated \
>>>>
>>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include
>>>> \
>>>>
>>>>
>>>> -I/home/tdaitx/build/jdk8-at60-power5/images/j2sdk-image/include/linux
>>>> \
>>>>
>>>> \
>>>>
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/salibelf.c
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/symtab.c
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.c
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_core.c
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/LinuxDebuggerLocal.c
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/share/native/sadis.c
>>>> \
>>>> -Xlinker
>>>>
>>>> --version-script=/home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/mapfile
>>>> -Wl,--hash-style=both \
>>>> \
>>>> -Wno-strict-aliasing -Werror
>>>> \
>>>> -o libsaproc.so
>>>> \
>>>> -lthread_db
>>>> In file included
>>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc.h:37:0,
>>>>
>>>> from
>>>> /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/libproc_impl.h:30,
>>>>
>>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:33:
>>>> /usr/include/linux/ptrace.h:58:8: error: redefinition of ?struct
>>>> ptrace_peeksiginfo_args?
>>>> struct ptrace_peeksiginfo_args {
>>>> ^
>>>> In file included
>>>> from /home/tdaitx/jdk9-dev/hotspot/agent/src/os/linux/ps_proc.c:32:0:
>>>> /usr/include/sys/ptrace.h:161:8: note: originally defined here
>>>> struct ptrace_peeksiginfo_args
>>>>
>>>>
>>>> Pasted at http://fpaste.org/110640/42657140/
>>>>
>>>> For JDK8 see: http://fpaste.org/110638/40304229/
>>>>
>>>> I see that both sys/ptrace.h and linux/ptrace.h have been included:
>>>>
>>>> $ grep -r ptrace.h hotspot/
>>>> hotspot/agent/src/os/linux/ps_proc.c:#include <sys/ptrace.h>
>>>> hotspot/agent/src/os/linux/libproc.h:#include <linux/ptrace.h>
>>>>
>>>> Usually linux/ptrace.h is used by glibc to do syscall, wile sys/ptrace.h
>>>> is used by app code to do library calls (thanks Maynard for the info).
>>>>
>>>> After editing hotspot/agent/src/os/linux/libproc.h to use sys/ptrace.h
>>>> I'm able to build both JDK8 & JDK9.
>>>>
>>>> Some settings:
>>>>
>>>> JDK8 configure:
>>>> $ ./configure \
>>>> --with-boot-jdk=/home/tdaitx/icedtea7/openjdk.build/j2sdk-image/ \
>>>> --with-jvm-variants=server --with-jvm-interpreter=cpp \
>>>> --with-extra-cflags=-Wno-strict-aliasing
>>>>
>>>> JDK9 configure is similar but I point it to a JDK8 build.
>>>>
>>>> Make for JDK8 and JDK9:
>>>> $ make JOBS=8 LOG=debug
>>>>
>>>>
>>>>
>>>> $ /usr/bin/gcc -v # g++ is the same, except for COLLECT_GCC
>>>> Using built-in specs.
>>>> COLLECT_GCC=/usr/bin/gcc
>>>>
>>>> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.2/lto-wrapper
>>>> Target: ppc64-redhat-linux
>>>> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
>>>> --infodir=/usr/share/info
>>>> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
>>>> --enable-shared --enable-threads=posix --enable-checking=release
>>>> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
>>>> --enable-gnu-unique-object --enable-linker-build-id
>>>> --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c
>>>> ++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array
>>>> --enable-java-awt=gtk --disable-dssi
>>>> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
>>>> --enable-libgcj-multifile --enable-java-maintainer-mode
>>>> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
>>>> --disable-libjava-multilib
>>>>
>>>> --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/isl-install
>>>> --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-ppc64-redhat-linux/cloog-install
>>>> --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
>>>> Thread model: posix
>>>> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
>>>>
>>>> $ cat /etc/redhat-release
>>>> Fedora release 20 (Heisenbug)
>>>>
>>>> $ rpm -qf /usr/include/linux/ptrace.h
>>>> kernel-headers-3.14.5-200.fc20.ppc64p7
>>>>
>>>> $ rpm -qf /usr/include/sys/ptrace.h
>>>> glibc-headers-2.18-12.fc20.ppc64p7
>>>>
>>>> Let me know if you need any additional info.
>>>>
>>>> Regards,
>>>> Tiago
>>>>
>>>
>>
>>
>
From stefan.karlsson at oracle.com Thu Jun 26 09:32:14 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 26 Jun 2014 11:32:14 +0200
Subject: RFR: 8047326: Add a version of CompiledIC_at that doesn't create
a new RelocIterator
In-Reply-To: <CE5B1BCB-70F2-4224-8821-C4D23F18DA6A@oracle.com>
References: <53A2DB59.9050605@oracle.com> <53A3038C.9020004@oracle.com>
<53A98296.5090604@oracle.com>
<CE5B1BCB-70F2-4224-8821-C4D23F18DA6A@oracle.com>
Message-ID: <53ABE89E.6030801@oracle.com>
On 2014-06-25 23:53, Igor Veresov wrote:
> Looks good. Very nice improvement.
Thanks, Igor!
>
> igor
>
> ps. We should probably get something like a BOT for the CodeCache. The reason RelocIterator's constructor is so bad is that it actually iterates over the whole code cache to find the blob that contains the start address. Ugh..
Actually, in the code I change we already have the nm setup, so we don't
have to search the code cache with:
if (nm == NULL && begin != NULL) {
// allow nmethod to be deduced from beginning address
CodeBlob* cb = CodeCache::find_blob(begin);
nm = cb->as_nmethod_or_null();
}
I think that the problem is that set_limits start from
relocation_begin() and searches it's way forward to the relocInfo we
want to visit, given the 'begin' parameter.
while (true) {
backup = _current;
backup_addr = _addr;
#ifdef ASSERT
if (backup == infoCheck) {
assert(backup_addr == addrCheck, "must match"); addrCheck =
NULL; infoCheck = NULL;
} else {
assert(addrCheck == NULL || backup_addr <= addrCheck, "must not
pass addrCheck");
}
#endif // ASSERT
if (!next() || addr() >= begin) break;
}
Since we already had the correct relocInfo in the original
relocIterator, this is unnecessary work.
thanks,
StefanK
>
>
> On Jun 24, 2014, at 6:52 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>
>> Hi all,
>>
>> Could someone from the Compiler team take a look and review/comment on this patch?
>>
>> thanks,
>> StefanK
>>
>> On 2014-06-19 17:36, Stefan Karlsson wrote:
>>> This was meant for the hotspot-dev list. BCC:ing hotspot-gc-dev.
>>>
>>> On 2014-06-19 14:45, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> I have a patch that we have been using in the G1 Class Unloading project to lower the remark times. This changes Compiler code, so I would like to get feedback from the Compiler team.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8047362/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8047362
>>>>
>>>> The patch builds upon the patch in:
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014358.html
>>>>
>>>>
>>>> Summary from the bug report:
>>>> ---
>>>> Creation of RelocIterators show up high in profiles of the remark phase, in the G1 Class Unloading project.
>>>>
>>>> There's a pattern in the nmethod/codecache code to create a RelocIterator and then materialize a CompiledIC:
>>>>
>>>> RelocIterator iter(this, low_boundary);
>>>> while(iter.next()) {
>>>> if (iter.type() == relocInfo::virtual_call_type) {
>>>> CompiledIC *ic = CompiledIC_at(iter.reloc());
>>>>
>>>> CompiledIC_at is implemented as:
>>>> new CompiledIC(call_site->code(), nativeCall_at(call_site->addr()));
>>>>
>>>> And one of the first thing CompiledIC::CompiledIC(const nmethod* nm, NativeCall* call) does is to create a new RelocIterator:
>>>> ...
>>>> address ic_call = call->instruction_address();
>>>> ...
>>>> RelocIterator iter(nm, ic_call, ic_call+1);
>>>> bool ret = iter.next();
>>>> assert(ret == true, "relocInfo must exist at this address");
>>>> assert(iter.addr() == ic_call, "must find ic_call");
>>>>
>>>> I would like to propose that we pass down the RelocIterator that we already have, instead of creating a new.
>>>> ---
>>>>
>>>>
>>>> I've previously received feedback that this seems like reasonable thing to do, but that the parameter to the new CompileIC_at should take a const RelocIterator* instead of RelocIterator*. I couldn't do that without changing a significant amount of Compiler code, so I have left it out for now. Any opinions on how to handle that?
>>>>
>>>>
>>>> To give an idea of the performance difference, I temporarily added the following code:
>>>> void CodeCache::iterate_through_CIs(int style) {
>>>> int count;
>>>> FOR_ALL_ALIVE_NMETHODS(nm) {
>>>> RelocIterator iter(nm);
>>>> while(iter.next()) {
>>>> if (iter.type() == relocInfo::virtual_call_type ||
>>>> iter.type() == relocInfo::opt_virtual_call_type) {
>>>> if (style > 0) {
>>>> CompiledIC *ic = style == 1 ? CompiledIC_at(&iter) : CompiledIC_at(iter.reloc());
>>>> if (ic->ic_destination() == (address)0xdeadb000) {
>>>> gclog_or_tty->print_cr("ShouldNotReachHere");
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>> and then measured how long time it took to execute iterate_through_CIs(style) 1000 times with style == {0, 1, 2}.
>>>>
>>>> The results are:
>>>> iterate_through_CIs(0): 1.210833 s // No CompiledICs created
>>>> iterate_through_CIs(1): 1.976557 s // New style
>>>> iterate_through_CIs(2): 9.924209 s // Old style
>>>>
>>>>
>>>> Testing:
>>>> A similar version has been used and thoroughly been tested together with the other G1 Class Unloading changes. This exact version has so far only been tested with Kitchensink and SpecJVM2008 compiler.compiler. What test lists would be appropriate to test this with?
>>>>
>>>>
>>>> thanks,
>>>> StefanK
>>>>
From volker.simonis at gmail.com Thu Jun 26 12:51:18 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Jun 2014 14:51:18 +0200
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <CA+3eh1102Wp_YW4sKoOaauwLo0OaNx-q=Oqw=DA66WXG9GQ=ew@mail.gmail.com>
References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com>
<5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com>
<539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com>
<539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com>
<CA+3eh1102Wp_YW4sKoOaauwLo0OaNx-q=Oqw=DA66WXG9GQ=ew@mail.gmail.com>
Message-ID: <CA+3eh110gMWePm-Ni+ULkA8ij+Fe=7qsPM=Hw03yMJ5NggNbag@mail.gmail.com>
OK, I've just realized that my comments were a little too late and the
change was submitted shortly after I sent the mail.
I'll try to put this tiny fix into the patch for 8048169 then which
already contains some other PPC64 related stuff anyway.
Regards,
Volker
On Mon, Jun 23, 2014 at 6:42 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi Mikael,
>
> sorry for the delayed answer - the PPC/AIX team was on holiday:)
>
> I've tested your changes on AIX and Linux/PPC64. On AIX everything works fine.
>
> For Linux/PPC64 there's a single occurrence of a test against $ARCH
> which you've missed:
>
> diff -r 116e9b1bf477 make/linux/Makefile
> --- a/make/linux/Makefile Mon Jun 23 17:43:30 2014 +0200
> +++ b/make/linux/Makefile Mon Jun 23 18:15:20 2014 +0200
> @@ -67,8 +67,10 @@
> endif
> endif
> # C1 is not ported on ppc64, so we cannot build a tiered VM:
> -ifeq ($(ARCH),ppc64)
> - FORCE_TIERED=0
> +ifeq ($(ARCH),ppc)
> + ifeq ($(ARCH_DATA_MODEL), 64)
> + FORCE_TIERED=0
> + endif
> endif
>
> ifdef LP64
>
> With this change I could successfully build on AIX and Linux/PPC64
> (I've only tested complete builds).
>
> Thank you and best regards,
> Volker
>
>
> On Tue, Jun 17, 2014 at 9:11 PM, Mikael Vidstedt
> <mikael.vidstedt at oracle.com> wrote:
>>
>> New webrev here (only the hotspot part, the webrev for top hasn't changed):
>>
>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/
>>
>> Comments inline.
>>
>>
>> On 2014-06-16 19:49, David Holmes wrote:
>>>
>>> Hi Mikael,
>>>
>>> Sorry for the delay ...
>>>
>>> make/aix/makefiles/defs.make:
>>>
>>> This change doesn't make sense to me:
>>>
>>> 48 ifneq (,$(findstring $(ARCH), ppc))
>>>
>>> given that the logic immediately preceding this sets ARCH to either ppc or
>>> ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for both
>>> 32-bit and 64-bit cross-builds but the earlier logic is really precluding
>>> this. So it seems to me that the changes in this file are completely
>>> unnecessary (or else the earlier logic also needs changing).
>>
>>
>> Indeed, that is correct - I missed the fact that ARCH is always overriden to
>> be either ppc or ppc64. The old logic is unnecessarily hard to follow, but I
>> guess that's in line with our hotspot Makefiles in general ;)
>>
>> I'll revert the changes to the file and add a mental note to self and others
>> that linux appears to be the only platform where the incoming value of ARCH
>> is actually honored - it's ignored/overridden on Solaris, BSD and AIX.
>>
>>
>>> make/linux/makefiles/defs.make
>>>
>>> This block:
>>>
>>> 86 # i686/i586 and amd64/x86_64
>>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
>>> 88 ifeq ($(ARCH_DATA_MODEL), 64)
>>> 89 ARCH_DATA_MODEL = 64
>>> 90 MAKE_ARGS += LP64=1
>>> 91 PLATFORM = linux-amd64
>>> 92 VM_PLATFORM = linux_amd64
>>> 93 HS_ARCH = x86
>>> 94 else
>>> 95 ARCH_DATA_MODEL = 32
>>> 96 PLATFORM = linux-i586
>>> 97 VM_PLATFORM = linux_i486
>>> 98 HS_ARCH = x86
>>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it
>>> 100 ARCH = i686
>>> 101 endif
>>> 102 endif
>>>
>>> seems to allow the user to try and do a 64-bit build on a 32-bit build
>>> machine. Not sure if that would get caught in an earlier sanity check? (Same
>>> is true for the sparc block).
>>
>>
>> While the changes are primarily just intended to cut down on the duplication
>> I don't immediately see the reason why we wouldn't want to allow compiling a
>> 64-bit VM from a 32-bit machine? We're cross compiling all sorts of
>> platforms, so why not allow this if the compiler supports it? I'd prefer to
>> keep it this way.
>>
>>
>>> Also I don't think the following is actually true:
>>>
>>> # We have to reset ARCH to i686 since SRCARCH relies on it
>>> ARCH = i686
>>>
>>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture
>>> designator will simply map to a SRCARCH of x86, as per defs.make:
>>>
>>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc
>>> zero,$(ARCH)))
>>> ARCH/ = x86
>>> ARCH/sparc = sparc
>>> ARCH/sparc64= sparc
>>> ARCH/ia64 = ia64
>>> ARCH/amd64 = x86
>>> ARCH/x86_64 = x86
>>> ARCH/ppc64 = ppc
>>> ARCH/ppc = ppc
>>> ARCH/arm = arm
>>> ARCH/zero = zero
>>
>>
>> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, ppc64,
>> ppc, arm, zero } it will map to x86 anyway. I thought about cleaning that up
>> before I sent out the first webrev, but soon found myself doing way more
>> cleanup than was healthy for this specific change. However, since I had to
>> update this change anyway I removed the ARCH reset part.
>>
>> Cheers,
>> Mikael
>>
>>
>>>
>>>
>>> Cheers,
>>> David
>>>
>>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>>>>
>>>>
>>>> Thanks Erik. Another review please?
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>> On 2014-06-12 23:56, Erik Joelsson wrote:
>>>>>
>>>>> Looks fine to me.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>>>>
>>>>>>
>>>>>> I have now verified that the changes work just fine for the platforms
>>>>>> we build and test - both from the top level and when building hotspot
>>>>>> only. Taking suggestions on other tests to perform. And it would be
>>>>>> great if somebody could test the changes on on aix/ppc.
>>>>>>
>>>>>> So, kindly asking for "real"/final reviews of the changes:
>>>>>>
>>>>>> top:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>> hotspot:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Mikael
>>>>>>
>>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>>>>
>>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>> Thanks for the feedback. Essentially the logic in the
>>>>>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>>>>>> two different use cases:
>>>>>>>
>>>>>>> 1. ARCH being set by the JDK build system to the value of
>>>>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>>>>> typically from uname
>>>>>>>
>>>>>>> Since Solaris and bsd both override ARCH they do not care about
>>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>>>>
>>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>>>>> the hope that somebody can help out with that.
>>>>>>>
>>>>>>>
>>>>>>> Summing it up, I have the following two webrevs:
>>>>>>>
>>>>>>> top:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>>
>>>>>>> hotspot:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>>
>>>>>>>
>>>>>>> With these changes I can build the normal platforms, but more
>>>>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>>>>> feedback is much appreciated!
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mikael
>>>>>>>
>>>>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>>>>>
>>>>>>>> Hi Mikael,
>>>>>>>>
>>>>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>>>>
>>>>>>>> As you note the main flow-on effect here is that the hotspot
>>>>>>>> makefiles have to be updated for the cases where
>>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>>>>> only x86 has that issue.
>>>>>>>>
>>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>>>>> both internally and in the build artifacts and bundles!
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> I need some feedback and comments on the below fix:
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>>>>
>>>>>>>>> Background:
>>>>>>>>>
>>>>>>>>> When configuring the hotspot build the build system sets up the ARCH
>>>>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>>>>> initialized
>>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>>>>> name. For
>>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>>>>>> The
>>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>>>>> gradually removed in favor of the other variables.
>>>>>>>>>
>>>>>>>>> Discussion:
>>>>>>>>>
>>>>>>>>> The two candidate variables to base ARCH on are as far as I can tell
>>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single,
>>>>>>>>> well
>>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }.
>>>>>>>>> Together
>>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>>>>> ignored on
>>>>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>>>>
>>>>>>>>> Before I go too far with this though I'd like to get some feedback
>>>>>>>>> on
>>>>>>>>> whether or not this is the right approach and what the exact value
>>>>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>>>>> system may
>>>>>>>>> have to be updated for some platforms to support the new value(s).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mikael
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
From volker.simonis at gmail.com Thu Jun 26 13:07:14 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Jun 2014 15:07:14 +0200
Subject: [patch] fixing the ppc64el hotspot build in 8u20-b16
In-Reply-To: <1403725923.3862.339.camel@ocdc.br.ibm.com>
References: <5390809A.5050800@ubuntu.com>
<1403725923.3862.339.camel@ocdc.br.ibm.com>
Message-ID: <CA+3eh13-54FEo_8n7E1dYEEBtsbqt5EE=NGHnyy5_R1vWcU=2A@mail.gmail.com>
Hi Tiago, Matthias,
sorry, I initially missed this mail because it was blocked by the list
(because Matthias is not a subscriber). I've added Matthias to the
list of accepted senders now, so this should not happen next time:)
Please see my other comments inline:
On Wed, Jun 25, 2014 at 9:52 PM, Tiago St?rmer Daitx <tdaitx at br.ibm.com> wrote:
> Cross-posting to hotspot-dev.
>
> On Thu, 2014-06-05 at 16:37 +0200, Matthias Klose wrote:
>> Hi,
>>
>> the ppc64el hotspot seems to be merged in 8u20-b16. However I got some build
>> failures building on ppc64el, fixed with the attached patch. Are you aware of
>> any other patches needed for the port?
>>
It seems you are trying to build the template interpreter for ppc64el.
This is currently not supported and even if you manage to build it, it
will probably not run. Alexander is currently working on the template
interpreter port for ppc64el but I don't know what's the current
status (cc-ed him). Alexander also did the ppc64el port of the
cpp-interpreter which should work.
So for the time being I'd suggest to take the cpp-interpreter for
ppc64el by using the configure option --with-jvm-interpreter=cpp
If you should run into warnigs/errors because of wrong printf format
arguments - I'm working on it and will submit a patch real soon (see
"8048169: Change 8037816 breaks HS build on PPC64 and CPP-Interpreter
platforms", https://bugs.openjdk.java.net/browse/JDK-8048169).
Regards,
Volker
>> Thanks, Matthias
>
>
> # Missing bits for the PPC ELF v2 ABI
>
> --- a/hotspot/src/cpu/ppc/vm/interp_masm_ppc_64.cpp
> +++ b/hotspot/src/cpu/ppc/vm/interp_masm_ppc_64.cpp
> @@ -119,9 +119,15 @@
> // Call the Interpreter::remove_activation_preserving_args_entry()
> // func to get the address of the same-named entrypoint in the
> // generated interpreter code.
> +#if !defined(ABI_ELFv2)
> call_c(CAST_FROM_FN_PTR(FunctionDescriptor*,
>
> Interpreter::remove_activation_preserving_args_entry),
> relocInfo::none);
> +#else
> + call_c(CAST_FROM_FN_PTR(address,
> +
> Interpreter::remove_activation_preserving_args_entry),
> + relocInfo::none);
> +#endif
>
> // Jump to Interpreter::_remove_activation_preserving_args_entry.
> mtctr(R3_RET);
> --- a/hotspot/src/cpu/ppc/vm/templateInterpreter_ppc.cpp
> +++ b/hotspot/src/cpu/ppc/vm/templateInterpreter_ppc.cpp
> @@ -1019,8 +1019,13 @@
> // native result across the call. No oop is present.
>
> __ mr(R3_ARG1, R16_thread);
> +#if !defined(ABI_ELFv2)
> __ call_c(CAST_FROM_FN_PTR(FunctionDescriptor*,
> JavaThread::check_special_condition_for_native_trans),
> relocInfo::none);
> +#else
> + __ call_c(CAST_FROM_FN_PTR(address,
> JavaThread::check_special_condition_for_native_trans),
> + relocInfo::none);
> +#endif
>
> __ bind(sync_check_done);
>
>
>
> --
> Tiago St?rmer Daitx
> Linux Technology Center [LTC|IBM]
> tdaitx at br.ibm.com
>
From volker.simonis at gmail.com Thu Jun 26 13:17:28 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Jun 2014 15:17:28 +0200
Subject: RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy
value for hotspot ARCH
In-Reply-To: <CA+3eh110gMWePm-Ni+ULkA8ij+Fe=7qsPM=Hw03yMJ5NggNbag@mail.gmail.com>
References: <53979E97.1040609@oracle.com> <5397C2E6.6080603@oracle.com>
<5397EEF7.5050006@oracle.com> <539A1939.80103@oracle.com>
<539AA0AC.6090202@oracle.com> <539F50E1.7090300@oracle.com>
<539FACB2.2050508@oracle.com> <53A092D4.3060100@oracle.com>
<CA+3eh1102Wp_YW4sKoOaauwLo0OaNx-q=Oqw=DA66WXG9GQ=ew@mail.gmail.com>
<CA+3eh110gMWePm-Ni+ULkA8ij+Fe=7qsPM=Hw03yMJ5NggNbag@mail.gmail.com>
Message-ID: <CA+3eh12XfVj2Psm-_Ou+aRZD6XLTh27pftUjGdLp=V1Ejdr22A@mail.gmail.com>
On Thu, Jun 26, 2014 at 2:51 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> OK, I've just realized that my comments were a little too late and the
> change was submitted shortly after I sent the mail.
>
> I'll try to put this tiny fix into the patch for 8048169 then which
> already contains some other PPC64 related stuff anyway.
>
I've decided to better create an own bug for this issue
(https://bugs.openjdk.java.net/browse/JDK-8048232) because 8048169
needs to be down-ported to jdk8 while this change doesn't.
Regards,
Volker
> Regards,
> Volker
>
>
> On Mon, Jun 23, 2014 at 6:42 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi Mikael,
>>
>> sorry for the delayed answer - the PPC/AIX team was on holiday:)
>>
>> I've tested your changes on AIX and Linux/PPC64. On AIX everything works fine.
>>
>> For Linux/PPC64 there's a single occurrence of a test against $ARCH
>> which you've missed:
>>
>> diff -r 116e9b1bf477 make/linux/Makefile
>> --- a/make/linux/Makefile Mon Jun 23 17:43:30 2014 +0200
>> +++ b/make/linux/Makefile Mon Jun 23 18:15:20 2014 +0200
>> @@ -67,8 +67,10 @@
>> endif
>> endif
>> # C1 is not ported on ppc64, so we cannot build a tiered VM:
>> -ifeq ($(ARCH),ppc64)
>> - FORCE_TIERED=0
>> +ifeq ($(ARCH),ppc)
>> + ifeq ($(ARCH_DATA_MODEL), 64)
>> + FORCE_TIERED=0
>> + endif
>> endif
>>
>> ifdef LP64
>>
>> With this change I could successfully build on AIX and Linux/PPC64
>> (I've only tested complete builds).
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Tue, Jun 17, 2014 at 9:11 PM, Mikael Vidstedt
>> <mikael.vidstedt at oracle.com> wrote:
>>>
>>> New webrev here (only the hotspot part, the webrev for top hasn't changed):
>>>
>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.02/hotspot/webrev/
>>>
>>> Comments inline.
>>>
>>>
>>> On 2014-06-16 19:49, David Holmes wrote:
>>>>
>>>> Hi Mikael,
>>>>
>>>> Sorry for the delay ...
>>>>
>>>> make/aix/makefiles/defs.make:
>>>>
>>>> This change doesn't make sense to me:
>>>>
>>>> 48 ifneq (,$(findstring $(ARCH), ppc))
>>>>
>>>> given that the logic immediately preceding this sets ARCH to either ppc or
>>>> ppc64 based on ARCH_DATA_MODEL. You seem to be trying to allow for both
>>>> 32-bit and 64-bit cross-builds but the earlier logic is really precluding
>>>> this. So it seems to me that the changes in this file are completely
>>>> unnecessary (or else the earlier logic also needs changing).
>>>
>>>
>>> Indeed, that is correct - I missed the fact that ARCH is always overriden to
>>> be either ppc or ppc64. The old logic is unnecessarily hard to follow, but I
>>> guess that's in line with our hotspot Makefiles in general ;)
>>>
>>> I'll revert the changes to the file and add a mental note to self and others
>>> that linux appears to be the only platform where the incoming value of ARCH
>>> is actually honored - it's ignored/overridden on Solaris, BSD and AIX.
>>>
>>>
>>>> make/linux/makefiles/defs.make
>>>>
>>>> This block:
>>>>
>>>> 86 # i686/i586 and amd64/x86_64
>>>> 87 ifneq (,$(findstring $(ARCH), amd64 x86_64 i686 i586))
>>>> 88 ifeq ($(ARCH_DATA_MODEL), 64)
>>>> 89 ARCH_DATA_MODEL = 64
>>>> 90 MAKE_ARGS += LP64=1
>>>> 91 PLATFORM = linux-amd64
>>>> 92 VM_PLATFORM = linux_amd64
>>>> 93 HS_ARCH = x86
>>>> 94 else
>>>> 95 ARCH_DATA_MODEL = 32
>>>> 96 PLATFORM = linux-i586
>>>> 97 VM_PLATFORM = linux_i486
>>>> 98 HS_ARCH = x86
>>>> 99 # We have to reset ARCH to i686 since SRCARCH relies on it
>>>> 100 ARCH = i686
>>>> 101 endif
>>>> 102 endif
>>>>
>>>> seems to allow the user to try and do a 64-bit build on a 32-bit build
>>>> machine. Not sure if that would get caught in an earlier sanity check? (Same
>>>> is true for the sparc block).
>>>
>>>
>>> While the changes are primarily just intended to cut down on the duplication
>>> I don't immediately see the reason why we wouldn't want to allow compiling a
>>> 64-bit VM from a 32-bit machine? We're cross compiling all sorts of
>>> platforms, so why not allow this if the compiler supports it? I'd prefer to
>>> keep it this way.
>>>
>>>
>>>> Also I don't think the following is actually true:
>>>>
>>>> # We have to reset ARCH to i686 since SRCARCH relies on it
>>>> ARCH = i686
>>>>
>>>> As long as ARCH is not amd64 and not x86_64 any 32-bit x86 architecture
>>>> designator will simply map to a SRCARCH of x86, as per defs.make:
>>>>
>>>> SRCARCH = $(ARCH/$(filter sparc sparc64 ia64 amd64 x86_64 arm ppc
>>>> zero,$(ARCH)))
>>>> ARCH/ = x86
>>>> ARCH/sparc = sparc
>>>> ARCH/sparc64= sparc
>>>> ARCH/ia64 = ia64
>>>> ARCH/amd64 = x86
>>>> ARCH/x86_64 = x86
>>>> ARCH/ppc64 = ppc
>>>> ARCH/ppc = ppc
>>>> ARCH/arm = arm
>>>> ARCH/zero = zero
>>>
>>>
>>> Indeed, I fully agree - as long as it's not { sparc, sparc64, ia64, ppc64,
>>> ppc, arm, zero } it will map to x86 anyway. I thought about cleaning that up
>>> before I sent out the first webrev, but soon found myself doing way more
>>> cleanup than was healthy for this specific change. However, since I had to
>>> update this change anyway I removed the ARCH reset part.
>>>
>>> Cheers,
>>> Mikael
>>>
>>>
>>>>
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>> On 17/06/2014 6:17 AM, Mikael Vidstedt wrote:
>>>>>
>>>>>
>>>>> Thanks Erik. Another review please?
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>> On 2014-06-12 23:56, Erik Joelsson wrote:
>>>>>>
>>>>>> Looks fine to me.
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> On 2014-06-12 23:18, Mikael Vidstedt wrote:
>>>>>>>
>>>>>>>
>>>>>>> I have now verified that the changes work just fine for the platforms
>>>>>>> we build and test - both from the top level and when building hotspot
>>>>>>> only. Taking suggestions on other tests to perform. And it would be
>>>>>>> great if somebody could test the changes on on aix/ppc.
>>>>>>>
>>>>>>> So, kindly asking for "real"/final reviews of the changes:
>>>>>>>
>>>>>>> top:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>> hotspot:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mikael
>>>>>>>
>>>>>>> On 2014-06-10 22:53, Mikael Vidstedt wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> David,
>>>>>>>>
>>>>>>>> Thanks for the feedback. Essentially the logic in the
>>>>>>>> make/<os>/makefiles/defs.make files needs to recognize and deal with
>>>>>>>> two different use cases:
>>>>>>>>
>>>>>>>> 1. ARCH being set by the JDK build system to the value of
>>>>>>>> OPENJDK_TARGET_CPU_ARCH, or
>>>>>>>> 2. no ARCH being set, in which case it needs to be populated -
>>>>>>>> typically from uname
>>>>>>>>
>>>>>>>> Since Solaris and bsd both override ARCH they do not care about
>>>>>>>> OPENJDK_TARGET_CPU_ARCH and effectively always go through case 2.
>>>>>>>>
>>>>>>>> Linux/x86 is where most of the difference (and confusion) is, but I
>>>>>>>> think aix/ppc64 will also change slightly since the ARCH value will
>>>>>>>> go from ppc64 to ppc. I've tried to make the relevant changes, but I
>>>>>>>> cannot verify that they actually work. cc:ing the ppc-aix list in
>>>>>>>> the hope that somebody can help out with that.
>>>>>>>>
>>>>>>>>
>>>>>>>> Summing it up, I have the following two webrevs:
>>>>>>>>
>>>>>>>> top:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/top/webrev/
>>>>>>>>
>>>>>>>> hotspot:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.01/hotspot/webrev/
>>>>>>>>
>>>>>>>>
>>>>>>>> With these changes I can build the normal platforms, but more
>>>>>>>> verification is needed - esp. building hotspot only. Meanwhile
>>>>>>>> feedback is much appreciated!
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Mikael
>>>>>>>>
>>>>>>>> On 2014-06-10 19:45, David Holmes wrote:
>>>>>>>>>
>>>>>>>>> Hi Mikael,
>>>>>>>>>
>>>>>>>>> This seems a reasonable proposal to me. We have an over-abundance
>>>>>>>>> of "arch" variables and values, so reducing that is a good aim.
>>>>>>>>>
>>>>>>>>> As you note the main flow-on effect here is that the hotspot
>>>>>>>>> makefiles have to be updated for the cases where
>>>>>>>>> OPENJDK_TARGET_CPU_ARCH and OPENJDK_TARGET_CPU_LEGACY differ so
>>>>>>>>> that it still sets LIBARCH, BUILDARCH, SRCARCH correctly. I think
>>>>>>>>> only x86 has that issue.
>>>>>>>>>
>>>>>>>>> Wouldn't it be nice if we could get rid of i386, i586, i686 etc
>>>>>>>>> both internally and in the build artifacts and bundles!
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> All,
>>>>>>>>>>
>>>>>>>>>> I need some feedback and comments on the below fix:
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
>>>>>>>>>>
>>>>>>>>>> Background:
>>>>>>>>>>
>>>>>>>>>> When configuring the hotspot build the build system sets up the ARCH
>>>>>>>>>> variable to reflect the target cpu. Currently the value is
>>>>>>>>>> initialized
>>>>>>>>>> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu
>>>>>>>>>> name. For
>>>>>>>>>> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac).
>>>>>>>>>> The
>>>>>>>>>> goal in the new (JDK) build system is to have the "legacy" value
>>>>>>>>>> gradually removed in favor of the other variables.
>>>>>>>>>>
>>>>>>>>>> Discussion:
>>>>>>>>>>
>>>>>>>>>> The two candidate variables to base ARCH on are as far as I can tell
>>>>>>>>>> OPENJDK_TARGET_CPU and OPENJDK_TARGET_CPU_ARCH. Of the two
>>>>>>>>>> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single,
>>>>>>>>>> well
>>>>>>>>>> defined value per cpu family { arm, ppc, s390, sparc, x86 }.
>>>>>>>>>> Together
>>>>>>>>>> with ARCH_DATA_MODEL/LP64 that information should be enough for the
>>>>>>>>>> Hotspot build system to do its thing. Note: ARCH is currently
>>>>>>>>>> ignored on
>>>>>>>>>> solaris and bsd - it's overridden at the top of the respective
>>>>>>>>>> make/<os>/makefiles/defs.make files.
>>>>>>>>>>
>>>>>>>>>> Before I go too far with this though I'd like to get some feedback
>>>>>>>>>> on
>>>>>>>>>> whether or not this is the right approach and what the exact value
>>>>>>>>>> should be. Depending on the outcome of that the Hotspot build
>>>>>>>>>> system may
>>>>>>>>>> have to be updated for some platforms to support the new value(s).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Mikael
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
From mikael.gerdin at oracle.com Thu Jun 26 14:18:58 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 26 Jun 2014 16:18:58 +0200
Subject: RFR: 8047326: Add a version of CompiledIC_at that doesn't create
a new RelocIterator
In-Reply-To: <5113836.YgHIQ7lM1y@mgerdin03>
References: <53A2DB59.9050605@oracle.com> <53A3038C.9020004@oracle.com>
<5113836.YgHIQ7lM1y@mgerdin03>
Message-ID: <1898495.XQJiaMVt6f@mgerdin03>
I replied to the wrong list, sorry.
Forwarding my review to hotspot-dev.
/Mikael
On Thursday 26 June 2014 16.16.36 Mikael Gerdin wrote:
> Hi,
>
> On Thursday 19 June 2014 17.36.44 Stefan Karlsson wrote:
> > This was meant for the hotspot-dev list. BCC:ing hotspot-gc-dev.
> >
> > On 2014-06-19 14:45, Stefan Karlsson wrote:
> > > Hi all,
> > >
> > > I have a patch that we have been using in the G1 Class Unloading
> > > project to lower the remark times. This changes Compiler code, so I
> > > would like to get feedback from the Compiler team.
> > >
> > > http://cr.openjdk.java.net/~stefank/8047362/webrev.00/
>
> The change looks good.
>
> I had an offline discussion with Steafan about this and we think that it
> would actually suffice to pass down the Relocation* since it appears to
> contain all the information needed to create the CompiledIC objects.
> However in the interest of moving forward with changes built on top of this
> we will look at that for a future cleanup.
>
> /Mikael
>
> > > https://bugs.openjdk.java.net/browse/JDK-8047362
> > >
> > > The patch builds upon the patch in:
> > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014358.html
> > >
> > >
> > > Summary from the bug report:
> > > ---
> > > Creation of RelocIterators show up high in profiles of the remark
> > > phase, in the G1 Class Unloading project.
> > >
> > > There's a pattern in the nmethod/codecache code to create a
> > >
> > > RelocIterator and then materialize a CompiledIC:
> > > RelocIterator iter(this, low_boundary);
> > > while(iter.next()) {
> > >
> > > if (iter.type() == relocInfo::virtual_call_type) {
> > >
> > > CompiledIC *ic = CompiledIC_at(iter.reloc());
> > >
> > > CompiledIC_at is implemented as:
> > > new CompiledIC(call_site->code(), nativeCall_at(call_site->addr()));
> > >
> > > And one of the first thing CompiledIC::CompiledIC(const nmethod* nm,
> > > NativeCall* call) does is to create a new RelocIterator:
> > > ...
> > > address ic_call = call->instruction_address();
> > > ...
> > >
> > > RelocIterator iter(nm, ic_call, ic_call+1);
> > > bool ret = iter.next();
> > > assert(ret == true, "relocInfo must exist at this address");
> > > assert(iter.addr() == ic_call, "must find ic_call");
> > >
> > > I would like to propose that we pass down the RelocIterator that we
> > > already have, instead of creating a new.
> > > ---
> > >
> > >
> > > I've previously received feedback that this seems like reasonable
> > > thing to do, but that the parameter to the new CompileIC_at should
> > > take a const RelocIterator* instead of RelocIterator*. I couldn't do
> > > that without changing a significant amount of Compiler code, so I have
> > > left it out for now. Any opinions on how to handle that?
> > >
> > >
> > > To give an idea of the performance difference, I temporarily added the
> > > following code:
> > > void CodeCache::iterate_through_CIs(int style) {
> > >
> > > int count;
> > > FOR_ALL_ALIVE_NMETHODS(nm) {
> > >
> > > RelocIterator iter(nm);
> > > while(iter.next()) {
> > >
> > > if (iter.type() == relocInfo::virtual_call_type ||
> > >
> > > iter.type() == relocInfo::opt_virtual_call_type) {
> > >
> > > if (style > 0) {
> > >
> > > CompiledIC *ic = style == 1 ? CompiledIC_at(&iter) :
> > > CompiledIC_at(iter.reloc());
> > >
> > > if (ic->ic_destination() == (address)0xdeadb000) {
> > >
> > > gclog_or_tty->print_cr("ShouldNotReachHere");
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > }
> > >
> > > and then measured how long time it took to execute
> > > iterate_through_CIs(style) 1000 times with style == {0, 1, 2}.
> > >
> > > The results are:
> > > iterate_through_CIs(0): 1.210833 s // No CompiledICs created
> > > iterate_through_CIs(1): 1.976557 s // New style
> > > iterate_through_CIs(2): 9.924209 s // Old style
> > >
> > > Testing:
> > > A similar version has been used and thoroughly been tested together
> > >
> > > with the other G1 Class Unloading changes. This exact version has so
> > > far only been tested with Kitchensink and SpecJVM2008
> > > compiler.compiler. What test lists would be appropriate to test this
> > > with?
> > >
> > >
> > > thanks,
> > > StefanK
From stefan.karlsson at oracle.com Thu Jun 26 14:12:09 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 26 Jun 2014 16:12:09 +0200
Subject: RFR: 8047326: Add a version of CompiledIC_at that doesn't create
a new RelocIterator
In-Reply-To: <1898495.XQJiaMVt6f@mgerdin03>
References: <53A2DB59.9050605@oracle.com>
<53A3038C.9020004@oracle.com> <5113836.YgHIQ7lM1y@mgerdin03>
<1898495.XQJiaMVt6f@mgerdin03>
Message-ID: <53AC2A39.2080400@oracle.com>
On 2014-06-26 16:18, Mikael Gerdin wrote:
> I replied to the wrong list, sorry.
> Forwarding my review to hotspot-dev.
>
> /Mikael
>
> On Thursday 26 June 2014 16.16.36 Mikael Gerdin wrote:
>> Hi,
>>
>> On Thursday 19 June 2014 17.36.44 Stefan Karlsson wrote:
>>> This was meant for the hotspot-dev list. BCC:ing hotspot-gc-dev.
>>>
>>> On 2014-06-19 14:45, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> I have a patch that we have been using in the G1 Class Unloading
>>>> project to lower the remark times. This changes Compiler code, so I
>>>> would like to get feedback from the Compiler team.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8047362/webrev.00/
>> The change looks good.
>>
>> I had an offline discussion with Steafan about this and we think that it
>> would actually suffice to pass down the Relocation* since it appears to
>> contain all the information needed to create the CompiledIC objects.
>> However in the interest of moving forward with changes built on top of this
>> we will look at that for a future cleanup.
Thanks.
StefanK
>>
>> /Mikael
>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8047362
>>>>
>>>> The patch builds upon the patch in:
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014358.html
>>>>
>>>>
>>>> Summary from the bug report:
>>>> ---
>>>> Creation of RelocIterators show up high in profiles of the remark
>>>> phase, in the G1 Class Unloading project.
>>>>
>>>> There's a pattern in the nmethod/codecache code to create a
>>>>
>>>> RelocIterator and then materialize a CompiledIC:
>>>> RelocIterator iter(this, low_boundary);
>>>> while(iter.next()) {
>>>>
>>>> if (iter.type() == relocInfo::virtual_call_type) {
>>>>
>>>> CompiledIC *ic = CompiledIC_at(iter.reloc());
>>>>
>>>> CompiledIC_at is implemented as:
>>>> new CompiledIC(call_site->code(), nativeCall_at(call_site->addr()));
>>>>
>>>> And one of the first thing CompiledIC::CompiledIC(const nmethod* nm,
>>>> NativeCall* call) does is to create a new RelocIterator:
>>>> ...
>>>> address ic_call = call->instruction_address();
>>>> ...
>>>>
>>>> RelocIterator iter(nm, ic_call, ic_call+1);
>>>> bool ret = iter.next();
>>>> assert(ret == true, "relocInfo must exist at this address");
>>>> assert(iter.addr() == ic_call, "must find ic_call");
>>>>
>>>> I would like to propose that we pass down the RelocIterator that we
>>>> already have, instead of creating a new.
>>>> ---
>>>>
>>>>
>>>> I've previously received feedback that this seems like reasonable
>>>> thing to do, but that the parameter to the new CompileIC_at should
>>>> take a const RelocIterator* instead of RelocIterator*. I couldn't do
>>>> that without changing a significant amount of Compiler code, so I have
>>>> left it out for now. Any opinions on how to handle that?
>>>>
>>>>
>>>> To give an idea of the performance difference, I temporarily added the
>>>> following code:
>>>> void CodeCache::iterate_through_CIs(int style) {
>>>>
>>>> int count;
>>>> FOR_ALL_ALIVE_NMETHODS(nm) {
>>>>
>>>> RelocIterator iter(nm);
>>>> while(iter.next()) {
>>>>
>>>> if (iter.type() == relocInfo::virtual_call_type ||
>>>>
>>>> iter.type() == relocInfo::opt_virtual_call_type) {
>>>>
>>>> if (style > 0) {
>>>>
>>>> CompiledIC *ic = style == 1 ? CompiledIC_at(&iter) :
>>>> CompiledIC_at(iter.reloc());
>>>>
>>>> if (ic->ic_destination() == (address)0xdeadb000) {
>>>>
>>>> gclog_or_tty->print_cr("ShouldNotReachHere");
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> and then measured how long time it took to execute
>>>> iterate_through_CIs(style) 1000 times with style == {0, 1, 2}.
>>>>
>>>> The results are:
>>>> iterate_through_CIs(0): 1.210833 s // No CompiledICs created
>>>> iterate_through_CIs(1): 1.976557 s // New style
>>>> iterate_through_CIs(2): 9.924209 s // Old style
>>>>
>>>> Testing:
>>>> A similar version has been used and thoroughly been tested together
>>>>
>>>> with the other G1 Class Unloading changes. This exact version has so
>>>> far only been tested with Kitchensink and SpecJVM2008
>>>> compiler.compiler. What test lists would be appropriate to test this
>>>> with?
>>>>
>>>>
>>>> thanks,
>>>> StefanK
From volker.simonis at gmail.com Thu Jun 26 14:25:22 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Jun 2014 16:25:22 +0200
Subject: RFR (XXS) [URGENT]: 8048232: Fix for 8046471 breaks PPC64 build
Message-ID: <CA+3eh10kC5t_4i_gdwvtu=bg4Jc=gqQuMn8o=u2xxjgX50=b3Q@mail.gmail.com>
Hi,
could somebody please review and push the following tiny change:
http://cr.openjdk.java.net/~simonis/webrevs/8048232/
https://bugs.openjdk.java.net/browse/JDK-8048232
It fixes the build on Linux/PPC64 after "8046471 Use
OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH".
Before 8046471, the top-level make passed ARCH=ppc64 to the HotSpot
make. After 8046471, it now passes ARCH=ppc. But there was one place
in make/linux/Makefile which checked for ARCH=ppc64 in order to
disable the TIERED build. This place has to be adapted to handle the
new ARCH value.
Please push this right to http://hg.openjdk.java.net/jdk9/hs/hotspot
in order to get it into http://hg.openjdk.java.net/jdk9/dev/hotspot
together with 8046471.
Note: this change depends on 8046471 in the hotspot AND in the
top-level directory!
Thank you and best regards,
Volker
From christian.thalinger at oracle.com Thu Jun 26 14:42:16 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 26 Jun 2014 07:42:16 -0700
Subject: [9] RFR(XS): 8007987: ciConstantPoolCache::_keys should be array
of 32bit int
In-Reply-To: <53AC1827.6060601@oracle.com>
References: <53AC1827.6060601@oracle.com>
Message-ID: <C28E4D73-7B9E-44B7-88FD-023C14D4C956@oracle.com>
Can you also have someone from the runtime team to take a quick look? Sending to hotspot-dev instead.
On Jun 26, 2014, at 5:55 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> Hi,
>
> please review the following small patch that changes the type of the keys stored in the array from intptr_t to int. This is sufficient to store the 2 byte constant pool indexes and conforms to the interface where int is used.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8007987
> Webrev: http://cr.openjdk.java.net/~thartmann/8007987/webrev.00/
> Testing: JPRT
>
> Thanks,
> Tobias
>
From coleen.phillimore at oracle.com Thu Jun 26 16:02:06 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 26 Jun 2014 12:02:06 -0400
Subject: [9] RFR(XS): 8007987: ciConstantPoolCache::_keys should be array
of 32bit int
In-Reply-To: <C28E4D73-7B9E-44B7-88FD-023C14D4C956@oracle.com>
References: <53AC1827.6060601@oracle.com>
<C28E4D73-7B9E-44B7-88FD-023C14D4C956@oracle.com>
Message-ID: <53AC43FE.7080705@oracle.com>
> // ciConstantPoolCache
> //
> // The class caches indexed constant pool lookups.
> //
> // Usage note: this klass has nothing to do with ConstantPoolCache*.
Oh my gosh.
If _keys corresponds to constant pool indices then an int is enough to
store the values, so this looks ok. The ConstantPool length is a u2 but
an int is better to future-proof this.
Coleen
On 6/26/14, 10:42 AM, Christian Thalinger wrote:
> Can you also have someone from the runtime team to take a quick look? Sending to hotspot-dev instead.
>
> On Jun 26, 2014, at 5:55 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>
>> Hi,
>>
>> please review the following small patch that changes the type of the keys stored in the array from intptr_t to int. This is sufficient to store the 2 byte constant pool indexes and conforms to the interface where int is used.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8007987
>> Webrev: http://cr.openjdk.java.net/~thartmann/8007987/webrev.00/
>> Testing: JPRT
>>
>> Thanks,
>> Tobias
>>
From asmundak at google.com Thu Jun 26 16:58:26 2014
From: asmundak at google.com (Alexander Smundak)
Date: Thu, 26 Jun 2014 09:58:26 -0700
Subject: [patch] fixing the ppc64el hotspot build in 8u20-b16
In-Reply-To: <CA+3eh13-54FEo_8n7E1dYEEBtsbqt5EE=NGHnyy5_R1vWcU=2A@mail.gmail.com>
References: <5390809A.5050800@ubuntu.com>
<1403725923.3862.339.camel@ocdc.br.ibm.com>
<CA+3eh13-54FEo_8n7E1dYEEBtsbqt5EE=NGHnyy5_R1vWcU=2A@mail.gmail.com>
Message-ID: <CAHQ51u4813d1nLrMHM5f0TqOaDkCck9cru5S-QgfDkcBrPyOpw@mail.gmail.com>
On Thu, Jun 26, 2014 at 6:07 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> It seems you are trying to build the template interpreter for ppc64el.
> This is currently not supported and even if you manage to build it, it
> will probably not run. Alexander is currently working on the template
> interpreter port for ppc64el but I don't know what's the current
> status (cc-ed him).
I was distracted by another project. I will get back to the template
interpreter port for ppc64el in two weeks.
From mikael.vidstedt at oracle.com Thu Jun 26 18:59:54 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 26 Jun 2014 11:59:54 -0700
Subject: RFR (XXS) [URGENT]: 8048232: Fix for 8046471 breaks PPC64 build
In-Reply-To: <CA+3eh10kC5t_4i_gdwvtu=bg4Jc=gqQuMn8o=u2xxjgX50=b3Q@mail.gmail.com>
References: <CA+3eh10kC5t_4i_gdwvtu=bg4Jc=gqQuMn8o=u2xxjgX50=b3Q@mail.gmail.com>
Message-ID: <53AC6DAA.2010807@oracle.com>
This will work for top level builds. For Hotspot-only builds ARCH will
(still) be the value of uname -m, so if you want to support Hotspot-only
builds you'll probably want to do the "ifneq (,$(findstring $(ARCH),
ppc))" trick to catch both "ppc" (which is what a top level build will
use) and "ppc64" (for Hotspot-only).
Sorry for breaking it.
Cheers,
Mikael
PS. We so need to clean up these makefiles...
On 2014-06-26 07:25, Volker Simonis wrote:
> Hi,
>
> could somebody please review and push the following tiny change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8048232/
> https://bugs.openjdk.java.net/browse/JDK-8048232
>
> It fixes the build on Linux/PPC64 after "8046471 Use
> OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH".
>
> Before 8046471, the top-level make passed ARCH=ppc64 to the HotSpot
> make. After 8046471, it now passes ARCH=ppc. But there was one place
> in make/linux/Makefile which checked for ARCH=ppc64 in order to
> disable the TIERED build. This place has to be adapted to handle the
> new ARCH value.
>
> Please push this right to http://hg.openjdk.java.net/jdk9/hs/hotspot
> in order to get it into http://hg.openjdk.java.net/jdk9/dev/hotspot
> together with 8046471.
>
> Note: this change depends on 8046471 in the hotspot AND in the
> top-level directory!
>
> Thank you and best regards,
> Volker
From coleen.phillimore at oracle.com Thu Jun 26 19:38:34 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 26 Jun 2014 15:38:34 -0400
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed:
type check
In-Reply-To: <53AAD54E.8090804@oracle.com>
References: <53AAD54E.8090804@oracle.com>
Message-ID: <53AC76BA.3010607@oracle.com>
Serguei,
This looks good.
Coleen
On 6/25/14, 9:57 AM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> https://bugs.openjdk.java.net/browse/JDK-8013942
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1
>
>
>
> Summary:
>
> This is a Nightly Stabilization issue.
>
> The problem is that the JVMTI GetLocalObject() function is hitting
> the assert
> as the type of the local at current bci is not T_OBJECT as expected.
> It is because this local is alive only in a narrow scope of one
> condition in the method but current bci is out of this csope.
>
> A fragment from the target method:
>
> static Class<?> canonicalize(Class<?> t, int how) {
> Class<?> ct; <== The local
> if (t == Object.class) {
> // no change, ever
> } else if (!t.isPrimitive()) {
> switch (how) {
> case UNWRAP:
> ct = Wrapper.asPrimitiveType(t); <== Initialized here
> if (ct != t) return ct;
> break;
> case RAW_RETURN:
> case ERASE:
> return Object.class;
> }
> } else if (t == void.class) { <== The
> GetLocalObject() is called with bci in this block
> // no change, usually
> switch (how) {
> case RAW_RETURN:
> return int.class;
> case WRAP:
> return Void.class;
> }
> } else {
> . . .
>
> The local 'ct' is only alive in the block of condition "if
> (!t.isPrimitive())".
> However, it is dead local in the next block.
>
> The fix suggested in the webrev above is to use the oop_mask for the
> method's current bci.
> It tells when the local is dead in the scope of this bci.
> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>
> The fix also includes the tweeks which are necessary to enable the
> InterpreterOopMap.is_dead()
> function in the product mode as it was originally defined only under
> "#ifdef ENABLE_ZAP_DEAD_LOCALS".
> This makes the code in the oopMapCache.?pp a little bit more simple.
>
>
> Testing:
> Running the failing tests: vm.mlvm.indy.func.jvmti
> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and
> amd64
>
>
> Thanks,
> Serguei
>
From volker.simonis at gmail.com Thu Jun 26 20:59:01 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Jun 2014 22:59:01 +0200
Subject: RFR (XXS) [URGENT]: 8048232: Fix for 8046471 breaks PPC64 build
In-Reply-To: <53AC6DAA.2010807@oracle.com>
References: <CA+3eh10kC5t_4i_gdwvtu=bg4Jc=gqQuMn8o=u2xxjgX50=b3Q@mail.gmail.com>
<53AC6DAA.2010807@oracle.com>
Message-ID: <CA+3eh111QO1cMHzROX+bWtfd58dZMjrT0k45YXX+Ti85LoTeYg@mail.gmail.com>
On Thursday, June 26, 2014, Mikael Vidstedt <mikael.vidstedt at oracle.com>
wrote:
>
> This will work for top level builds. For Hotspot-only builds ARCH will
> (still) be the value of uname -m, so if you want to support Hotspot-only
> builds you'll probably want to do the "ifneq (,$(findstring $(ARCH), ppc))"
> trick to catch both "ppc" (which is what a top level build will use) and
> "ppc64" (for Hotspot-only).
>
> Hi Mikael,
yes you're right. I only tested a complete make but I indeed want to
support HotSpot only makes as well. I'll change it as requested although I
won't have chance to do that before tomorrow morning (European time).
Thanks you and best regards,
Volker
> Sorry for breaking it.
>
> Cheers,
> Mikael
>
> PS. We so need to clean up these makefiles...
>
> On 2014-06-26 07:25, Volker Simonis wrote:
>
>> Hi,
>>
>> could somebody please review and push the following tiny change:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8048232/
>> https://bugs.openjdk.java.net/browse/JDK-8048232
>>
>> It fixes the build on Linux/PPC64 after "8046471 Use
>> OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH".
>>
>> Before 8046471, the top-level make passed ARCH=ppc64 to the HotSpot
>> make. After 8046471, it now passes ARCH=ppc. But there was one place
>> in make/linux/Makefile which checked for ARCH=ppc64 in order to
>> disable the TIERED build. This place has to be adapted to handle the
>> new ARCH value.
>>
>> Please push this right to http://hg.openjdk.java.net/jdk9/hs/hotspot
>> in order to get it into http://hg.openjdk.java.net/jdk9/dev/hotspot
>> together with 8046471.
>>
>> Note: this change depends on 8046471 in the hotspot AND in the
>> top-level directory!
>>
>> Thank you and best regards,
>> Volker
>>
>
>
From serguei.spitsyn at oracle.com Thu Jun 26 21:54:59 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 26 Jun 2014 14:54:59 -0700
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed:
type check
In-Reply-To: <53AC76BA.3010607@oracle.com>
References: <53AAD54E.8090804@oracle.com> <53AC76BA.3010607@oracle.com>
Message-ID: <53AC96B3.5040705@oracle.com>
Thanks, Coleen!
Serguei
On 6/26/14 12:38 PM, Coleen Phillimore wrote:
>
> Serguei,
> This looks good.
> Coleen
>
> On 6/25/14, 9:57 AM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8013942
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1
>>
>>
>>
>> Summary:
>>
>> This is a Nightly Stabilization issue.
>>
>> The problem is that the JVMTI GetLocalObject() function is hitting
>> the assert
>> as the type of the local at current bci is not T_OBJECT as expected.
>> It is because this local is alive only in a narrow scope of one
>> condition in the method but current bci is out of this csope.
>>
>> A fragment from the target method:
>>
>> static Class<?> canonicalize(Class<?> t, int how) {
>> Class<?> ct; <== The local
>> if (t == Object.class) {
>> // no change, ever
>> } else if (!t.isPrimitive()) {
>> switch (how) {
>> case UNWRAP:
>> ct = Wrapper.asPrimitiveType(t); <== Initialized
>> here
>> if (ct != t) return ct;
>> break;
>> case RAW_RETURN:
>> case ERASE:
>> return Object.class;
>> }
>> } else if (t == void.class) { <== The
>> GetLocalObject() is called with bci in this block
>> // no change, usually
>> switch (how) {
>> case RAW_RETURN:
>> return int.class;
>> case WRAP:
>> return Void.class;
>> }
>> } else {
>> . . .
>>
>> The local 'ct' is only alive in the block of condition "if
>> (!t.isPrimitive())".
>> However, it is dead local in the next block.
>>
>> The fix suggested in the webrev above is to use the oop_mask for
>> the method's current bci.
>> It tells when the local is dead in the scope of this bci.
>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>>
>> The fix also includes the tweeks which are necessary to enable the
>> InterpreterOopMap.is_dead()
>> function in the product mode as it was originally defined only
>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS".
>> This makes the code in the oopMapCache.?pp a little bit more simple.
>>
>>
>> Testing:
>> Running the failing tests: vm.mlvm.indy.func.jvmti
>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and
>> amd64
>>
>>
>> Thanks,
>> Serguei
>>
>
From vladimir.x.ivanov at oracle.com Thu Jun 26 22:02:05 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 27 Jun 2014 02:02:05 +0400
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed:
type check
In-Reply-To: <53AAD54E.8090804@oracle.com>
References: <53AAD54E.8090804@oracle.com>
Message-ID: <53AC985D.6080806@oracle.com>
Looks good.
Best regards,
Vladimir Ivanov
On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> https://bugs.openjdk.java.net/browse/JDK-8013942
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1
>
>
>
> Summary:
>
> This is a Nightly Stabilization issue.
>
> The problem is that the JVMTI GetLocalObject() function is hitting
> the assert
> as the type of the local at current bci is not T_OBJECT as expected.
> It is because this local is alive only in a narrow scope of one
> condition in the method but current bci is out of this csope.
>
> A fragment from the target method:
>
> static Class<?> canonicalize(Class<?> t, int how) {
> Class<?> ct; <== The local
> if (t == Object.class) {
> // no change, ever
> } else if (!t.isPrimitive()) {
> switch (how) {
> case UNWRAP:
> ct = Wrapper.asPrimitiveType(t); <== Initialized here
> if (ct != t) return ct;
> break;
> case RAW_RETURN:
> case ERASE:
> return Object.class;
> }
> } else if (t == void.class) { <== The
> GetLocalObject() is called with bci in this block
> // no change, usually
> switch (how) {
> case RAW_RETURN:
> return int.class;
> case WRAP:
> return Void.class;
> }
> } else {
> . . .
>
> The local 'ct' is only alive in the block of condition "if
> (!t.isPrimitive())".
> However, it is dead local in the next block.
>
> The fix suggested in the webrev above is to use the oop_mask for the
> method's current bci.
> It tells when the local is dead in the scope of this bci.
> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>
> The fix also includes the tweeks which are necessary to enable the
> InterpreterOopMap.is_dead()
> function in the product mode as it was originally defined only under
> "#ifdef ENABLE_ZAP_DEAD_LOCALS".
> This makes the code in the oopMapCache.?pp a little bit more simple.
>
>
> Testing:
> Running the failing tests: vm.mlvm.indy.func.jvmti
> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and amd64
>
>
> Thanks,
> Serguei
>
From serguei.spitsyn at oracle.com Thu Jun 26 22:15:28 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 26 Jun 2014 15:15:28 -0700
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed:
type check
In-Reply-To: <53AC985D.6080806@oracle.com>
References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com>
Message-ID: <53AC9B80.9030805@oracle.com>
Thanks, Vladimir!
Serguei
On 6/26/14 3:02 PM, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8013942
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.1
>>
>>
>>
>>
>> Summary:
>>
>> This is a Nightly Stabilization issue.
>>
>> The problem is that the JVMTI GetLocalObject() function is hitting
>> the assert
>> as the type of the local at current bci is not T_OBJECT as expected.
>> It is because this local is alive only in a narrow scope of one
>> condition in the method but current bci is out of this csope.
>>
>> A fragment from the target method:
>>
>> static Class<?> canonicalize(Class<?> t, int how) {
>> Class<?> ct; <== The local
>> if (t == Object.class) {
>> // no change, ever
>> } else if (!t.isPrimitive()) {
>> switch (how) {
>> case UNWRAP:
>> ct = Wrapper.asPrimitiveType(t); <== Initialized
>> here
>> if (ct != t) return ct;
>> break;
>> case RAW_RETURN:
>> case ERASE:
>> return Object.class;
>> }
>> } else if (t == void.class) { <== The
>> GetLocalObject() is called with bci in this block
>> // no change, usually
>> switch (how) {
>> case RAW_RETURN:
>> return int.class;
>> case WRAP:
>> return Void.class;
>> }
>> } else {
>> . . .
>>
>> The local 'ct' is only alive in the block of condition "if
>> (!t.isPrimitive())".
>> However, it is dead local in the next block.
>>
>> The fix suggested in the webrev above is to use the oop_mask for the
>> method's current bci.
>> It tells when the local is dead in the scope of this bci.
>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>>
>> The fix also includes the tweeks which are necessary to enable the
>> InterpreterOopMap.is_dead()
>> function in the product mode as it was originally defined only under
>> "#ifdef ENABLE_ZAP_DEAD_LOCALS".
>> This makes the code in the oopMapCache.?pp a little bit more simple.
>>
>>
>> Testing:
>> Running the failing tests: vm.mlvm.indy.func.jvmti
>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and
>> amd64
>>
>>
>> Thanks,
>> Serguei
>>
From tobias.hartmann at oracle.com Fri Jun 27 07:01:28 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 27 Jun 2014 09:01:28 +0200
Subject: [9] RFR(XS): 8007987: ciConstantPoolCache::_keys should be array
of 32bit int
In-Reply-To: <53AC43FE.7080705@oracle.com>
References: <53AC1827.6060601@oracle.com> <C28E4D73-7B9E-44B7-88FD-023C14D4C956@oracle.com>
<53AC43FE.7080705@oracle.com>
Message-ID: <53AD16C8.9020000@oracle.com>
Hi Coleen,
thanks for the review.
>> // ciConstantPoolCache
>> //
>> // The class caches indexed constant pool lookups.
>> //
>> // Usage note: this klass has nothing to do with ConstantPoolCache*.
> Oh my gosh.
Yes, that comment is a little bit confusing.
> If _keys corresponds to constant pool indices then an int is enough to
> store the values, so this looks ok. The ConstantPool length is a u2
> but an int is better to future-proof this.
I think so too.
Thanks,
Tobias
>
> Coleen
>
> On 6/26/14, 10:42 AM, Christian Thalinger wrote:
>> Can you also have someone from the runtime team to take a quick
>> look? Sending to hotspot-dev instead.
>>
>> On Jun 26, 2014, at 5:55 AM, Tobias Hartmann
>> <tobias.hartmann at oracle.com> wrote:
>>
>>> Hi,
>>>
>>> please review the following small patch that changes the type of the
>>> keys stored in the array from intptr_t to int. This is sufficient to
>>> store the 2 byte constant pool indexes and conforms to the interface
>>> where int is used.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8007987
>>> Webrev: http://cr.openjdk.java.net/~thartmann/8007987/webrev.00/
>>> Testing: JPRT
>>>
>>> Thanks,
>>> Tobias
>>>
>
From markus.gronlund at oracle.com Fri Jun 27 08:12:23 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Fri, 27 Jun 2014 01:12:23 -0700 (PDT)
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type
check
In-Reply-To: <53AC9B80.9030805@oracle.com>
References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com>
<53AC9B80.9030805@oracle.com>
Message-ID: <b0621477-b209-46db-8678-9b6a24cb87ce@default>
Hi Serguei,
I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words.
This means the oopmap bitmap cache is effectively halved unconditionally.
/Markus
-----Original Message-----
From: Serguei Spitsyn
Sent: den 27 juni 2014 00:15
To: Vladimir Ivanov; hotspot-dev at openjdk.java.net Developers; serviceability-dev at openjdk.java.net
Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check
Thanks, Vladimir!
Serguei
On 6/26/14 3:02 PM, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8013942
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM
>> TI-lobj.1
>>
>>
>>
>>
>> Summary:
>>
>> This is a Nightly Stabilization issue.
>>
>> The problem is that the JVMTI GetLocalObject() function is hitting
>> the assert
>> as the type of the local at current bci is not T_OBJECT as expected.
>> It is because this local is alive only in a narrow scope of one
>> condition in the method but current bci is out of this csope.
>>
>> A fragment from the target method:
>>
>> static Class<?> canonicalize(Class<?> t, int how) {
>> Class<?> ct; <== The local
>> if (t == Object.class) {
>> // no change, ever
>> } else if (!t.isPrimitive()) {
>> switch (how) {
>> case UNWRAP:
>> ct = Wrapper.asPrimitiveType(t); <== Initialized
>> here
>> if (ct != t) return ct;
>> break;
>> case RAW_RETURN:
>> case ERASE:
>> return Object.class;
>> }
>> } else if (t == void.class) { <== The
>> GetLocalObject() is called with bci in this block
>> // no change, usually
>> switch (how) {
>> case RAW_RETURN:
>> return int.class;
>> case WRAP:
>> return Void.class;
>> }
>> } else {
>> . . .
>>
>> The local 'ct' is only alive in the block of condition "if
>> (!t.isPrimitive())".
>> However, it is dead local in the next block.
>>
>> The fix suggested in the webrev above is to use the oop_mask for
>> the method's current bci.
>> It tells when the local is dead in the scope of this bci.
>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>>
>> The fix also includes the tweeks which are necessary to enable the
>> InterpreterOopMap.is_dead()
>> function in the product mode as it was originally defined only
>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS".
>> This makes the code in the oopMapCache.?pp a little bit more simple.
>>
>>
>> Testing:
>> Running the failing tests: vm.mlvm.indy.func.jvmti
>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and
>> amd64
>>
>>
>> Thanks,
>> Serguei
>>
From serguei.spitsyn at oracle.com Fri Jun 27 08:34:23 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 27 Jun 2014 01:34:23 -0700
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed:
type check
In-Reply-To: <b0621477-b209-46db-8678-9b6a24cb87ce@default>
References: <53AAD54E.8090804@oracle.com> <53AC985D.6080806@oracle.com>
<53AC9B80.9030805@oracle.com>
<b0621477-b209-46db-8678-9b6a24cb87ce@default>
Message-ID: <53AD2C8F.9090702@oracle.com>
Hi Markus,
I raised a good point, thanks!
What do you think about increasing the predefined size (N from 2 to 4)?
64 class InterpreterOopMap: ResourceObj {
65 friend class OopMapCache;
66
67 public:
68 enum {
69 N = 2, // the number of words reserved
70 // for inlined mask storage
71 small_mask_limit = N * BitsPerWord, // the maximum number of bits
72 // available for small masks,
73 // small_mask_limit can be set to 0
74 // for testing bit_mask allocation
Thanks,
Serguei
On 6/27/14 1:12 AM, Markus Gr?nlund wrote:
> Hi Serguei,
>
>
> I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words.
>
> This means the oopmap bitmap cache is effectively halved unconditionally.
>
> /Markus
>
>
> -----Original Message-----
> From: Serguei Spitsyn
> Sent: den 27 juni 2014 00:15
> To: Vladimir Ivanov; hotspot-dev at openjdk.java.net Developers; serviceability-dev at openjdk.java.net
> Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check
>
> Thanks, Vladimir!
> Serguei
>
> On 6/26/14 3:02 PM, Vladimir Ivanov wrote:
>> Looks good.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 6/25/14 5:57 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8013942
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM
>>> TI-lobj.1
>>>
>>>
>>>
>>>
>>> Summary:
>>>
>>> This is a Nightly Stabilization issue.
>>>
>>> The problem is that the JVMTI GetLocalObject() function is hitting
>>> the assert
>>> as the type of the local at current bci is not T_OBJECT as expected.
>>> It is because this local is alive only in a narrow scope of one
>>> condition in the method but current bci is out of this csope.
>>>
>>> A fragment from the target method:
>>>
>>> static Class<?> canonicalize(Class<?> t, int how) {
>>> Class<?> ct; <== The local
>>> if (t == Object.class) {
>>> // no change, ever
>>> } else if (!t.isPrimitive()) {
>>> switch (how) {
>>> case UNWRAP:
>>> ct = Wrapper.asPrimitiveType(t); <== Initialized
>>> here
>>> if (ct != t) return ct;
>>> break;
>>> case RAW_RETURN:
>>> case ERASE:
>>> return Object.class;
>>> }
>>> } else if (t == void.class) { <== The
>>> GetLocalObject() is called with bci in this block
>>> // no change, usually
>>> switch (how) {
>>> case RAW_RETURN:
>>> return int.class;
>>> case WRAP:
>>> return Void.class;
>>> }
>>> } else {
>>> . . .
>>>
>>> The local 'ct' is only alive in the block of condition "if
>>> (!t.isPrimitive())".
>>> However, it is dead local in the next block.
>>>
>>> The fix suggested in the webrev above is to use the oop_mask for
>>> the method's current bci.
>>> It tells when the local is dead in the scope of this bci.
>>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>>>
>>> The fix also includes the tweeks which are necessary to enable the
>>> InterpreterOopMap.is_dead()
>>> function in the product mode as it was originally defined only
>>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS".
>>> This makes the code in the oopMapCache.?pp a little bit more simple.
>>>
>>>
>>> Testing:
>>> Running the failing tests: vm.mlvm.indy.func.jvmti
>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and
>>> amd64
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
From serguei.spitsyn at oracle.com Fri Jun 27 08:53:34 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 27 Jun 2014 01:53:34 -0700
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed:
type check
In-Reply-To: <53AD2C8F.9090702@oracle.com>
References: <53AAD54E.8090804@oracle.com>
<53AC985D.6080806@oracle.com> <53AC9B80.9030805@oracle.com> <b0621477-b209-46db-8678-9b6a24cb87ce@default>
<53AD2C8F.9090702@oracle.com>
Message-ID: <53AD310E.1010200@oracle.com>
On 6/27/14 1:34 AM, serguei.spitsyn at oracle.com wrote:
> Hi Markus,
>
> I raised a good point, thanks!
Sorry, I wanted to say: "You raised a good point!" :)
> What do you think about increasing the predefined size (N from 2 to 4)?
>
> 64 class InterpreterOopMap: ResourceObj {
> 65 friend class OopMapCache;
> 66
> 67 public:
> 68 enum {
> 69 N = 2, // the number of words reserved
> 70 // for inlined mask storage
> 71 small_mask_limit = N * BitsPerWord, // the maximum number of bits
> 72 // available for small masks,
> 73 // small_mask_limit can be set to 0
> 74 // for testing bit_mask allocation
>
>
> Thanks,
> Serguei
>
> On 6/27/14 1:12 AM, Markus Gr?nlund wrote:
>> Hi Serguei,
>>
>>
>> I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words.
>>
>> This means the oopmap bitmap cache is effectively halved unconditionally.
>>
>> /Markus
>>
>>
>> -----Original Message-----
>> From: Serguei Spitsyn
>> Sent: den 27 juni 2014 00:15
>> To: Vladimir Ivanov;hotspot-dev at openjdk.java.net Developers;serviceability-dev at openjdk.java.net
>> Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check
>>
>> Thanks, Vladimir!
>> Serguei
>>
>> On 6/26/14 3:02 PM, Vladimir Ivanov wrote:
>>> Looks good.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 6/25/14 5:57 PM,serguei.spitsyn at oracle.com wrote:
>>>> Please, review the fix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8013942
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM
>>>> TI-lobj.1
>>>>
>>>>
>>>>
>>>>
>>>> Summary:
>>>>
>>>> This is a Nightly Stabilization issue.
>>>>
>>>> The problem is that the JVMTI GetLocalObject() function is hitting
>>>> the assert
>>>> as the type of the local at current bci is not T_OBJECT as expected.
>>>> It is because this local is alive only in a narrow scope of one
>>>> condition in the method but current bci is out of this csope.
>>>>
>>>> A fragment from the target method:
>>>>
>>>> static Class<?> canonicalize(Class<?> t, int how) {
>>>> Class<?> ct; <== The local
>>>> if (t == Object.class) {
>>>> // no change, ever
>>>> } else if (!t.isPrimitive()) {
>>>> switch (how) {
>>>> case UNWRAP:
>>>> ct = Wrapper.asPrimitiveType(t); <== Initialized
>>>> here
>>>> if (ct != t) return ct;
>>>> break;
>>>> case RAW_RETURN:
>>>> case ERASE:
>>>> return Object.class;
>>>> }
>>>> } else if (t == void.class) { <== The
>>>> GetLocalObject() is called with bci in this block
>>>> // no change, usually
>>>> switch (how) {
>>>> case RAW_RETURN:
>>>> return int.class;
>>>> case WRAP:
>>>> return Void.class;
>>>> }
>>>> } else {
>>>> . . .
>>>>
>>>> The local 'ct' is only alive in the block of condition "if
>>>> (!t.isPrimitive())".
>>>> However, it is dead local in the next block.
>>>>
>>>> The fix suggested in the webrev above is to use the oop_mask for
>>>> the method's current bci.
>>>> It tells when the local is dead in the scope of this bci.
>>>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>>>>
>>>> The fix also includes the tweeks which are necessary to enable the
>>>> InterpreterOopMap.is_dead()
>>>> function in the product mode as it was originally defined only
>>>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS".
>>>> This makes the code in the oopMapCache.?pp a little bit more simple.
>>>>
>>>>
>>>> Testing:
>>>> Running the failing tests: vm.mlvm.indy.func.jvmti
>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and
>>>> amd64
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>
From volker.simonis at gmail.com Fri Jun 27 15:48:01 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 27 Jun 2014 17:48:01 +0200
Subject: RFR (XXS) [URGENT]: 8048232: Fix for 8046471 breaks PPC64 build
In-Reply-To: <CA+3eh111QO1cMHzROX+bWtfd58dZMjrT0k45YXX+Ti85LoTeYg@mail.gmail.com>
References: <CA+3eh10kC5t_4i_gdwvtu=bg4Jc=gqQuMn8o=u2xxjgX50=b3Q@mail.gmail.com>
<53AC6DAA.2010807@oracle.com>
<CA+3eh111QO1cMHzROX+bWtfd58dZMjrT0k45YXX+Ti85LoTeYg@mail.gmail.com>
Message-ID: <CA+3eh130-74UG0XE0JzDcWUd3VaGMQRqpTQ09gbg+Loq5i9mkw@mail.gmail.com>
On Thu, Jun 26, 2014 at 10:59 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
>
>
> On Thursday, June 26, 2014, Mikael Vidstedt <mikael.vidstedt at oracle.com>
> wrote:
>>
>>
>> This will work for top level builds. For Hotspot-only builds ARCH will
>> (still) be the value of uname -m, so if you want to support Hotspot-only
>> builds you'll probably want to do the "ifneq (,$(findstring $(ARCH), ppc))"
>> trick to catch both "ppc" (which is what a top level build will use) and
>> "ppc64" (for Hotspot-only).
>>
> Hi Mikael,
>
> yes you're right.
I have to correct myself - you're nearly right:)
In the term "$(findstring $(ARCH), ppc)" '$ARCH' is the needle and
'ppc is the stack, so it won't catch 'ppc64' either. I could write
"$(findstring ppc, $(ARCH))" which would catch both, 'ppc' and 'ppc64'
but I decided to use the slightly more verbose "$(findstring $(ARCH),
ppc ppc64)" because it seemed clearer to me. I also added a comment to
explain the problematic of the different ARCH values for top-level and
HotSpot-only builds. Once we have the new HS build, this can hopefully
all go away.
By, the way, I also had to apply this change to your ppc-modifications
in make/linux/makefiles/defs.make. And I think that the same reasoning
may also apply to "$(findstring $(ARCH), sparc)" which won't catch
'sparc64' any more after your change but I have no Linux/SPARC box to
test this. You may change it accordingly at your discretion.
So here's the new webrev:
http://cr.openjdk.java.net/~simonis/webrevs/8048232.v2/
Please review and sponsor:)
Thank you and best regards,
Volker
> I only tested a complete make but I indeed want to support
> HotSpot only makes as well. I'll change it as requested although I won't
> have chance to do that before tomorrow morning (European time).
>
> Thanks you and best regards,
> Volker
>
>>
>> Sorry for breaking it.
>>
>> Cheers,
>> Mikael
>>
>> PS. We so need to clean up these makefiles...
>>
>> On 2014-06-26 07:25, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> could somebody please review and push the following tiny change:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8048232/
>>> https://bugs.openjdk.java.net/browse/JDK-8048232
>>>
>>> It fixes the build on Linux/PPC64 after "8046471 Use
>>> OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH".
>>>
>>> Before 8046471, the top-level make passed ARCH=ppc64 to the HotSpot
>>> make. After 8046471, it now passes ARCH=ppc. But there was one place
>>> in make/linux/Makefile which checked for ARCH=ppc64 in order to
>>> disable the TIERED build. This place has to be adapted to handle the
>>> new ARCH value.
>>>
>>> Please push this right to http://hg.openjdk.java.net/jdk9/hs/hotspot
>>> in order to get it into http://hg.openjdk.java.net/jdk9/dev/hotspot
>>> together with 8046471.
>>>
>>> Note: this change depends on 8046471 in the hotspot AND in the
>>> top-level directory!
>>>
>>> Thank you and best regards,
>>> Volker
>>
>>
>
From volker.simonis at gmail.com Fri Jun 27 16:20:58 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 27 Jun 2014 18:20:58 +0200
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
Message-ID: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com>
Hi,
this is a follow-up for change "8037816: Fix for 8036122 breaks build
with Xcode5/clang". It fixes the matching of format string parameter
types to the actual argument types for the PPC64 and CPP-Interpreter
files in the same way as 8037816 already did it for all the other
files (so mainly insertions of 'p2i()' calls and some manual casts).
http://cr.openjdk.java.net/~simonis/webrevs/8048169/
https://bugs.openjdk.java.net/browse/JDK-8048169
This change only touches PPC64 and the two CPP-Interpreter files
src/share/vm/interpreter/bytecodeInterpreter.cpp and
src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
Please review and sponsor.
Thank you and best regards,
Volker
From coleen.phillimore at oracle.com Fri Jun 27 19:24:04 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 27 Jun 2014 15:24:04 -0400
Subject: RFR 8047737 Move array component mirror to instance of java/lang/Class
Message-ID: <53ADC4D4.4030403@oracle.com>
Summary: Add field in java.lang.Class for componentType to simplify oop
processing and intrinsics in JVM
This is part of ongoing work to clean up oop pointers in the metadata
and simplify the interface between the JDK j.l.C and the JVM. There's a
performance benefit at the end of all of this if we can remove all oop
pointers from metadata. mirror in Klass is the only one left after
this full change.
See bug https://bugs.openjdk.java.net/browse/JDK-8047737
There are a couple steps to this change because Hotspot testing is done
with promoted JDKs. The first step is this webrev:
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
When the JDK is promoted, the code to remove
ArrayKlass::_component_mirror will be changed under a new bug id.
http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
Finally, a compatibility request and licensee notification will occur to
remove the function JVM_GetComponentType.
Performance testing was done that shows no difference in performance.
The isArray() call is a compiler intrinsic which is now called instead
of getComponentType, which was recognized as a compiler intrinsic.
JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
tests were performed on both the change requested (1st one) and the full
change.
hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
Please send your comments.
Thanks,
Coleen
From vladimir.danushevsky at oracle.com Fri Jun 27 21:58:52 2014
From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky)
Date: Fri, 27 Jun 2014 17:58:52 -0400
Subject: RFR: 8048554: C2: Pass AES lookup tables for platforms with no HW
crypto acceleration
Message-ID: <6F653FA9-7E55-49F0-AC19-EBFDA9E1A6DE@oracle.com>
Enable passing AES cipher implementation specific lookup tables to an intrinsic stub in order to to accelerate processing.
The lookup tables could be used on targets where no HW acceleration support is present.
https://bugs.openjdk.java.net/browse/JDK-8048554
The change also enables static fields support in LibraryCallKit::load_field_from_object().
Please review:
http://cr.openjdk.java.net/~vladidan/8048554/
Thanks,
Vlad
From joe.darcy at oracle.com Fri Jun 27 23:57:21 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 27 Jun 2014 16:57:21 -0700
Subject: JDK 9 RFR of JDK-8048620: Remove unneeded/obsolete -source/-target
options in hotspot tests
Message-ID: <53AE04E1.4000806@oracle.com>
Hello,
As a consequence of a policy for retiring old javac -source and -target
options (JEP 182 [1]), in JDK 9, only -source/-target of 6/1.6 and
higher will be supported [2]. This work is being tracked under bug
JDK-8011044: Remove support for 1.5 and earlier source and target
options
https://bugs.openjdk.java.net/browse/JDK-8011044
Many subtasks related to this are already complete, including updating
regression tests in the jdk and langtools repos. It has come to my
attention that the hotspot repo also has a few tests that use -source
and -target that should be updated. Please review the changes:
http://cr.openjdk.java.net/~darcy/8048620.0/
Full patch below. From what I could tell looking at the bug and tests,
these tests are not sensitive to the class file version so they
shouldn't need to use an explicit -source or -target option and should
just accept the JDK-default.
There is one additional test which uses -source/-target,
test/compiler/6932496/Test6932496.java. This test *does* appear
sensitive to class file version (no jsr / jret instruction in target 6
or higher) so I have not modified this test. If the test is not actually
sensitive to class file version, it can be updated like the others. If
it is sensitive and if testing this is still relevant, the class file in
question will need to be generated in some other way, such as as by
using ASM.
Regardless of the outcome of the technical discussion around
Test6932496.java, I'd appreciate if a "hotspot buddy" could shepherd
this fix through the HotSpot processes.
Thanks,
-Joe
[1] http://openjdk.java.net/jeps/182
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-January/000328.html
--- old/test/compiler/6775880/Test.java 2014-06-27 16:24:25.000000000
-0700
+++ new/test/compiler/6775880/Test.java 2014-06-27 16:24:25.000000000
-0700
@@ -26,7 +26,6 @@
* @test
* @bug 6775880
* @summary EA +DeoptimizeALot:
assert(mon_info->owner()->is_locked(),"object must be locked now")
- * @compile -source 1.4 -target 1.4 Test.java
* @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xbatch
-XX:+DoEscapeAnalysis -XX:+DeoptimizeALot
-XX:CompileCommand=exclude,java.lang.AbstractStringBuilder::append Test
*/
--- old/test/runtime/6626217/Test6626217.sh 2014-06-27
16:24:26.000000000 -0700
+++ new/test/runtime/6626217/Test6626217.sh 2014-06-27
16:24:26.000000000 -0700
@@ -54,7 +54,7 @@
# Compile all the usual suspects, including the default 'many_loader'
${CP} many_loader1.java.foo many_loader.java
-${JAVAC} ${TESTJAVACOPTS} -source 1.4 -target 1.4 -Xlint *.java
+${JAVAC} ${TESTJAVACOPTS} -Xlint *.java
# Rename the class files, so the custom loader (and not the system
loader) will find it
${MV} from_loader2.class from_loader2.impl2
@@ -62,7 +62,7 @@
# Compile the next version of 'many_loader'
${MV} many_loader.class many_loader.impl1
${CP} many_loader2.java.foo many_loader.java
-${JAVAC} ${TESTJAVACOPTS} -source 1.4 -target 1.4 -Xlint many_loader.java
+${JAVAC} ${TESTJAVACOPTS} -Xlint many_loader.java
# Rename the class file, so the custom loader (and not the system
loader) will find it
${MV} many_loader.class many_loader.impl2
--- old/test/runtime/8003720/Test8003720.java 2014-06-27
16:24:26.000000000 -0700
+++ new/test/runtime/8003720/Test8003720.java 2014-06-27
16:24:26.000000000 -0700
@@ -26,7 +26,7 @@
* @test
* @bug 8003720
* @summary Method in interpreter stack frame can be deallocated
- * @compile -XDignore.symbol.file -source 1.7 -target 1.7 Victim.java
+ * @compile -XDignore.symbol.file Victim.java
* @run main/othervm -Xverify:all -Xint Test8003720
*/
From rbonifacio123 at gmail.com Sat Jun 28 13:52:33 2014
From: rbonifacio123 at gmail.com (Rodrigo Bonifacio)
Date: Sat, 28 Jun 2014 10:52:33 -0300
Subject: Code convention
Message-ID: <9CDFA0E7-3A18-4967-B747-51539ED1B577@gmail.com>
Dear all, is there any code guideline that recommends developers to avoid the use of C++ exception handling mechanisms within the open jdk hotspot development?
All the best,
Rodrigo.
From stefan.karlsson at oracle.com Sat Jun 28 19:25:18 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Sat, 28 Jun 2014 21:25:18 +0200
Subject: Code convention
In-Reply-To: <9CDFA0E7-3A18-4967-B747-51539ED1B577@gmail.com>
References: <9CDFA0E7-3A18-4967-B747-51539ED1B577@gmail.com>
Message-ID: <53AF169E.8030907@oracle.com>
Hi Rodrigo,
On 2014-06-28 15:52, Rodrigo Bonifacio wrote:
> Dear all, is there any code guideline that recommends developers to avoid the use of C++ exception handling mechanisms within the open jdk hotspot development?
See this page:
https://wiki.openjdk.java.net/display/HotSpot/StyleGuide
StefanK
>
> All the best,
>
> Rodrigo.
From goetz.lindenmaier at sap.com Sun Jun 29 21:00:46 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sun, 29 Jun 2014 21:00:46 +0000
Subject: RFR (M): 8048241: Introduce umbrella header os.inline.hpp and clean
up includes
Message-ID: <4295855A5C1DE049A61835A1887419CC2CED7FF4@DEWDFEMB12A.global.corp.sap>
Hi,
This change adds a new header os.inline.hpp including the os_<os>.include.hpp
headers. This allows to remove around 30 os dependent include cascades, some of
them even without adding the os.inline.hpp header in that file.
Also, os.inline.hpp is added in several files that call functions from these
headers where it was missing so far.
Some further cleanups:
OrderAccess include in adaptiveFreeList.cpp is needed because of freeChunk.hpp.
The include of os.inline.hpp in thread.inline.hpp is needed because
Thread::current() uses thread() from ThreadLocalStorage, which again uses
os::thread_local_storage_at which is implemented platform dependent.
I moved some methods without dependencies to other .include.hpp files
to os_windows.hpp/os_posix.hpp. This reduces the need for os.inline.hpp
includes a lot.
Please review and test this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/webrevs/8048241-osInc/webrev.00/
I compiled and tested this without precompiled headers on linuxx86_64,
linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64,
aixppc64 in opt, dbg and fastdbg versions.
Thanks and best regards,
Goetz.
From david.holmes at oracle.com Mon Jun 30 05:55:59 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jun 2014 15:55:59 +1000
Subject: RFR 8047737 Move array component mirror to instance of
java/lang/Class
In-Reply-To: <53ADC4D4.4030403@oracle.com>
References: <53ADC4D4.4030403@oracle.com>
Message-ID: <53B0FBEF.5030607@oracle.com>
Hi Coleen,
Your webrev links are to internal locations.
David
On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
> Summary: Add field in java.lang.Class for componentType to simplify oop
> processing and intrinsics in JVM
>
> This is part of ongoing work to clean up oop pointers in the metadata
> and simplify the interface between the JDK j.l.C and the JVM. There's a
> performance benefit at the end of all of this if we can remove all oop
> pointers from metadata. mirror in Klass is the only one left after
> this full change.
>
> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>
> There are a couple steps to this change because Hotspot testing is done
> with promoted JDKs. The first step is this webrev:
>
> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>
> When the JDK is promoted, the code to remove
> ArrayKlass::_component_mirror will be changed under a new bug id.
>
> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>
> Finally, a compatibility request and licensee notification will occur to
> remove the function JVM_GetComponentType.
>
> Performance testing was done that shows no difference in performance.
> The isArray() call is a compiler intrinsic which is now called instead
> of getComponentType, which was recognized as a compiler intrinsic.
>
> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
> tests were performed on both the change requested (1st one) and the full
> change.
>
> hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
>
> Please send your comments.
>
> Thanks,
> Coleen
From tobias.hartmann at oracle.com Mon Jun 30 06:24:02 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 30 Jun 2014 08:24:02 +0200
Subject: [9] RFR(XS): 8007987: ciConstantPoolCache::_keys should be array
of 32bit int
In-Reply-To: <53AD16C8.9020000@oracle.com>
References: <53AC1827.6060601@oracle.com> <C28E4D73-7B9E-44B7-88FD-023C14D4C956@oracle.com> <53AC43FE.7080705@oracle.com>
<53AD16C8.9020000@oracle.com>
Message-ID: <53B10282.3070202@oracle.com>
Hi,
can we push this one or do I need another review?
Thanks,
Tobias
On 27.06.2014 09:01, Tobias Hartmann wrote:
> Hi Coleen,
>
> thanks for the review.
>
>>> // ciConstantPoolCache
>>> //
>>> // The class caches indexed constant pool lookups.
>>> //
>>> // Usage note: this klass has nothing to do with ConstantPoolCache*.
>> Oh my gosh.
>
> Yes, that comment is a little bit confusing.
>
>> If _keys corresponds to constant pool indices then an int is enough
>> to store the values, so this looks ok. The ConstantPool length is a
>> u2 but an int is better to future-proof this.
>
> I think so too.
>
> Thanks,
> Tobias
>
>>
>> Coleen
>>
>> On 6/26/14, 10:42 AM, Christian Thalinger wrote:
>>> Can you also have someone from the runtime team to take a quick
>>> look? Sending to hotspot-dev instead.
>>>
>>> On Jun 26, 2014, at 5:55 AM, Tobias Hartmann
>>> <tobias.hartmann at oracle.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> please review the following small patch that changes the type of
>>>> the keys stored in the array from intptr_t to int. This is
>>>> sufficient to store the 2 byte constant pool indexes and conforms
>>>> to the interface where int is used.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8007987
>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8007987/webrev.00/
>>>> Testing: JPRT
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>
>
From david.holmes at oracle.com Mon Jun 30 07:53:09 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jun 2014 17:53:09 +1000
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com>
Message-ID: <53B11765.1020107@oracle.com>
Hi Volker,
Two minor queries:
src/share/vm/interpreter/bytecodeInterpreter.cpp
+ (int)(istate->bcp() - METHOD->code_base()),
Not clear that this is an int result - what type are the operands?
+ tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
this->_oop_temp);
uintptr_t or intptr_t ? (Yes I see the existing code has the same
mismatch but I don't understand why.)
David
-----
On 28/06/2014 2:20 AM, Volker Simonis wrote:
> Hi,
>
> this is a follow-up for change "8037816: Fix for 8036122 breaks build
> with Xcode5/clang". It fixes the matching of format string parameter
> types to the actual argument types for the PPC64 and CPP-Interpreter
> files in the same way as 8037816 already did it for all the other
> files (so mainly insertions of 'p2i()' calls and some manual casts).
>
> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
> https://bugs.openjdk.java.net/browse/JDK-8048169
>
> This change only touches PPC64 and the two CPP-Interpreter files
> src/share/vm/interpreter/bytecodeInterpreter.cpp and
> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>
> Please review and sponsor.
>
> Thank you and best regards,
> Volker
>
From aph at redhat.com Mon Jun 30 08:48:17 2014
From: aph at redhat.com (Andrew Haley)
Date: Mon, 30 Jun 2014 09:48:17 +0100
Subject: Compressed-OOP's on =?UTF-8?B?SlZN4oCP?=
In-Reply-To: <DUB129-W19CAF8C9FE98CF58DA3F25D91A0@phx.gbl>
References: <DUB129-W19CAF8C9FE98CF58DA3F25D91A0@phx.gbl>
Message-ID: <53B12451.6090701@redhat.com>
On 28/06/14 13:21, serkan ?zal wrote:
> In 64 bit JVM with compressed-oops enable and and with minimum heap
> size 1G and maximum heap size 1G, object references are 4 byte. In
> this case, compressed-oop is real native address.
> But in 64 bit JVM with compressed-oops enable and and with minimum
> heap size 4G and maximum heap size 8G, object references are 4
> byte. But in this case, compressed-oop is needed to be
> encoded/decoded (by 3 bit shifting) before getting real native
> address.
> In both of cases, compressed-oop is enable, but how can I detect
> compressed-oops are used as native address or are they need to be
> encoded/decoded ?
Like this:
$ java -Xmx1G -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -XX:HeapBaseMinAddress=1G -version
heap address: 0x0000000040000000, size: 1024 MB, zero based Compressed Oops, 32-bits Oops
Narrow klass base: 0x0000000000000000, Narrow klass shift: 0
Compressed class space size: 1073741824 Address: 0x0000000080000000 Req Addr: 0x0000000080000000
openjdk version "1.8.0-internal"
> If they are encoded/decoded, what is the value of bit shifting ?
I'm not sure what this refers to.
Andrew.
From filipp.zhinkin at oracle.com Mon Jun 30 08:49:57 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Mon, 30 Jun 2014 12:49:57 +0400
Subject: Compressed-OOP's on =?UTF-8?B?SlZN4oCP?=
In-Reply-To: <53B12451.6090701@redhat.com>
References: <DUB129-W19CAF8C9FE98CF58DA3F25D91A0@phx.gbl>
<53B12451.6090701@redhat.com>
Message-ID: <53B124B5.4050602@oracle.com>
On 06/30/2014 12:48 PM, Andrew Haley wrote:
> On 28/06/14 13:21, serkan ?zal wrote:
>
>> In 64 bit JVM with compressed-oops enable and and with minimum heap
>> size 1G and maximum heap size 1G, object references are 4 byte. In
>> this case, compressed-oop is real native address.
>> But in 64 bit JVM with compressed-oops enable and and with minimum
>> heap size 4G and maximum heap size 8G, object references are 4
>> byte. But in this case, compressed-oop is needed to be
>> encoded/decoded (by 3 bit shifting) before getting real native
>> address.
>> In both of cases, compressed-oop is enable, but how can I detect
>> compressed-oops are used as native address or are they need to be
>> encoded/decoded ?
> Like this:
>
> $ java -Xmx1G -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -XX:HeapBaseMinAddress=1G -version
>
> heap address: 0x0000000040000000, size: 1024 MB, zero based Compressed Oops, 32-bits Oops
>
> Narrow klass base: 0x0000000000000000, Narrow klass shift: 0
> Compressed class space size: 1073741824 Address: 0x0000000080000000 Req Addr: 0x0000000080000000
> openjdk version "1.8.0-internal"
>
>> If they are encoded/decoded, what is the value of bit shifting ?
It is determined as binary logarithm of ObjectAlignmentInBytes' value.
Default value of that option is 8 bytes, so value of bit shifting is 3.
Regards,
Filipp.
> I'm not sure what this refers to.
>
> Andrew.
From aleksey.shipilev at oracle.com Mon Jun 30 10:08:54 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 30 Jun 2014 14:08:54 +0400
Subject: Compressed-OOP's on =?UTF-8?B?SlZN4oCP?=
In-Reply-To: <53B124B5.4050602@oracle.com>
References: <DUB129-W19CAF8C9FE98CF58DA3F25D91A0@phx.gbl> <53B12451.6090701@redhat.com>
<53B124B5.4050602@oracle.com>
Message-ID: <53B13736.9060507@oracle.com>
On 06/30/2014 12:49 PM, Filipp Zhinkin wrote:
> On 06/30/2014 12:48 PM, Andrew Haley wrote:
>> On 28/06/14 13:21, serkan ?zal wrote:
>>
>>> In 64 bit JVM with compressed-oops enable and and with minimum heap
>>> size 1G and maximum heap size 1G, object references are 4 byte. In
>>> this case, compressed-oop is real native address.
>>> But in 64 bit JVM with compressed-oops enable and and with minimum
>>> heap size 4G and maximum heap size 8G, object references are 4
>>> byte. But in this case, compressed-oop is needed to be
>>> encoded/decoded (by 3 bit shifting) before getting real native
>>> address.
>>> In both of cases, compressed-oop is enable, but how can I detect
>>> compressed-oops are used as native address or are they need to be
>>> encoded/decoded ?
>> Like this:
>>
>> $ java -Xmx1G -XX:+UnlockDiagnosticVMOptions
>> -XX:+PrintCompressedOopsMode -XX:HeapBaseMinAddress=1G -version
>>
>> heap address: 0x0000000040000000, size: 1024 MB, zero based Compressed
>> Oops, 32-bits Oops
>>
>> Narrow klass base: 0x0000000000000000, Narrow klass shift: 0
>> Compressed class space size: 1073741824 Address: 0x0000000080000000
>> Req Addr: 0x0000000080000000
>> openjdk version "1.8.0-internal"
>>
>>> If they are encoded/decoded, what is the value of bit shifting ?
> It is determined as binary logarithm of ObjectAlignmentInBytes' value.
> Default value of that option is 8 bytes, so value of bit shifting is 3.
See also:
http://openjdk.java.net/projects/code-tools/jol/
...and specifically
http://hg.openjdk.java.net/code-tools/jol/file/b4bc510cbad0/jol-core/src/main/java/org/openjdk/jol/util/VMSupport.java
Hotspot Serviceability Agent (SA) should be able to decode these as well
without guessing.
-Aleksey.
From coleen.phillimore at oracle.com Mon Jun 30 12:42:56 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 08:42:56 -0400
Subject: RFR 8047737 Move array component mirror to instance of
java/lang/Class
In-Reply-To: <53B0FBEF.5030607@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
Message-ID: <53B15B50.6070405@oracle.com>
On 6/30/14, 1:55 AM, David Holmes wrote:
> Hi Coleen,
>
> Your webrev links are to internal locations.
Sorry, I cut/pasted the wrong links. They are:
http://cr.openjdk.java.net/~coleenp/8047737_jdk/
http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
and the full version
http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
Thank you for pointing this out David.
Coleen
>
> David
>
> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>> Summary: Add field in java.lang.Class for componentType to simplify oop
>> processing and intrinsics in JVM
>>
>> This is part of ongoing work to clean up oop pointers in the metadata
>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>> performance benefit at the end of all of this if we can remove all oop
>> pointers from metadata. mirror in Klass is the only one left after
>> this full change.
>>
>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>
>> There are a couple steps to this change because Hotspot testing is done
>> with promoted JDKs. The first step is this webrev:
>>
>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>
>> When the JDK is promoted, the code to remove
>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>
>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>
>> Finally, a compatibility request and licensee notification will occur to
>> remove the function JVM_GetComponentType.
>>
>> Performance testing was done that shows no difference in performance.
>> The isArray() call is a compiler intrinsic which is now called instead
>> of getComponentType, which was recognized as a compiler intrinsic.
>>
>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>> tests were performed on both the change requested (1st one) and the full
>> change.
>>
>> hotspot NSK tests were run on the hotspot-only change with a promoted
>> JDK.
>>
>> Please send your comments.
>>
>> Thanks,
>> Coleen
From volker.simonis at gmail.com Mon Jun 30 14:25:30 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 30 Jun 2014 16:25:30 +0200
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <53B11765.1020107@oracle.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com>
<53B11765.1020107@oracle.com>
Message-ID: <CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com>
Hi David,
thanks for looking at the change. Please find my answers inline
On Mon, Jun 30, 2014 at 9:53 AM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Volker,
>
> Two minor queries:
>
> src/share/vm/interpreter/bytecodeInterpreter.cpp
>
> + (int)(istate->bcp() - METHOD->code_base()),
>
> Not clear that this is an int result - what type are the operands?
The operands are both 'address' (aka 'char*') so the actual result
type would be 'ptrdiff_t'. But at this place, we subtract the code
base from the current byte code pointer the result of which should be
a short integer. I therefore think the cast should be OK.
>
> + tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
> this->_oop_temp);
>
> uintptr_t or intptr_t ? (Yes I see the existing code has the same mismatch
> but I don't understand why.)
This code is there since the first OpenJDK checkin and as fas as I can
see it was added with 6u10.
I think it's just the name INTPTR_FORMAT which is a little misleading.
Actually INTPTR_FORMAT is defined as:
#ifdef _LP64
#define INTPTR_FORMAT "0x%016" PRIxPTR
#define PTR_FORMAT "0x%016" PRIxPTR
#else // !_LP64
#define INTPTR_FORMAT "0x%08" PRIxPTR
#define PTR_FORMAT "0x%08" PRIxPTR
#endif // _LP64
in globalDefinitions.hpp and "PRIxPTR" is the specifier for printing
an "uintptr_t" (as defined in inttypes.h by C99).
Strictly speaking, I think INTPTR_FORMAT should really be defined to
PRIiPTR (or PRIdPTR) which could then be used to output signed values.
On the other hand PTR_FORMAT should be used in the code only for
printing unsigned hex values. But there are currently hundreds of
places where INTPTR_FORMAT is used for printing unsigned hex values so
that would be another XXL change.
Regards,
Volker
>
> David
> -----
>
>
> On 28/06/2014 2:20 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> this is a follow-up for change "8037816: Fix for 8036122 breaks build
>> with Xcode5/clang". It fixes the matching of format string parameter
>> types to the actual argument types for the PPC64 and CPP-Interpreter
>> files in the same way as 8037816 already did it for all the other
>> files (so mainly insertions of 'p2i()' calls and some manual casts).
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
>> https://bugs.openjdk.java.net/browse/JDK-8048169
>>
>> This change only touches PPC64 and the two CPP-Interpreter files
>> src/share/vm/interpreter/bytecodeInterpreter.cpp and
>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>>
>> Please review and sponsor.
>>
>> Thank you and best regards,
>> Volker
>>
>
From volker.simonis at gmail.com Mon Jun 30 14:28:02 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 30 Jun 2014 16:28:02 +0200
Subject: RFR (XXS) [URGENT]: 8048232: Fix for 8046471 breaks PPC64 build
In-Reply-To: <CA+3eh130-74UG0XE0JzDcWUd3VaGMQRqpTQ09gbg+Loq5i9mkw@mail.gmail.com>
References: <CA+3eh10kC5t_4i_gdwvtu=bg4Jc=gqQuMn8o=u2xxjgX50=b3Q@mail.gmail.com>
<53AC6DAA.2010807@oracle.com>
<CA+3eh111QO1cMHzROX+bWtfd58dZMjrT0k45YXX+Ti85LoTeYg@mail.gmail.com>
<CA+3eh130-74UG0XE0JzDcWUd3VaGMQRqpTQ09gbg+Loq5i9mkw@mail.gmail.com>
Message-ID: <CA+3eh11bhqtd0+w8nftN4pGoY0ZywfTrdse+-aPh7ktXL-Cupw@mail.gmail.com>
Can somebody please review and push this small build change to fix our
ppc64 build errors.
Thanks,
Volker
On Fri, Jun 27, 2014 at 5:48 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> On Thu, Jun 26, 2014 at 10:59 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>>
>>
>> On Thursday, June 26, 2014, Mikael Vidstedt <mikael.vidstedt at oracle.com>
>> wrote:
>>>
>>>
>>> This will work for top level builds. For Hotspot-only builds ARCH will
>>> (still) be the value of uname -m, so if you want to support Hotspot-only
>>> builds you'll probably want to do the "ifneq (,$(findstring $(ARCH), ppc))"
>>> trick to catch both "ppc" (which is what a top level build will use) and
>>> "ppc64" (for Hotspot-only).
>>>
>> Hi Mikael,
>>
>> yes you're right.
>
> I have to correct myself - you're nearly right:)
>
> In the term "$(findstring $(ARCH), ppc)" '$ARCH' is the needle and
> 'ppc is the stack, so it won't catch 'ppc64' either. I could write
> "$(findstring ppc, $(ARCH))" which would catch both, 'ppc' and 'ppc64'
> but I decided to use the slightly more verbose "$(findstring $(ARCH),
> ppc ppc64)" because it seemed clearer to me. I also added a comment to
> explain the problematic of the different ARCH values for top-level and
> HotSpot-only builds. Once we have the new HS build, this can hopefully
> all go away.
>
> By, the way, I also had to apply this change to your ppc-modifications
> in make/linux/makefiles/defs.make. And I think that the same reasoning
> may also apply to "$(findstring $(ARCH), sparc)" which won't catch
> 'sparc64' any more after your change but I have no Linux/SPARC box to
> test this. You may change it accordingly at your discretion.
>
> So here's the new webrev:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8048232.v2/
>
> Please review and sponsor:)
>
> Thank you and best regards,
> Volker
>
>> I only tested a complete make but I indeed want to support
>> HotSpot only makes as well. I'll change it as requested although I won't
>> have chance to do that before tomorrow morning (European time).
>>
>> Thanks you and best regards,
>> Volker
>>
>>>
>>> Sorry for breaking it.
>>>
>>> Cheers,
>>> Mikael
>>>
>>> PS. We so need to clean up these makefiles...
>>>
>>> On 2014-06-26 07:25, Volker Simonis wrote:
>>>>
>>>> Hi,
>>>>
>>>> could somebody please review and push the following tiny change:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/8048232/
>>>> https://bugs.openjdk.java.net/browse/JDK-8048232
>>>>
>>>> It fixes the build on Linux/PPC64 after "8046471 Use
>>>> OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH".
>>>>
>>>> Before 8046471, the top-level make passed ARCH=ppc64 to the HotSpot
>>>> make. After 8046471, it now passes ARCH=ppc. But there was one place
>>>> in make/linux/Makefile which checked for ARCH=ppc64 in order to
>>>> disable the TIERED build. This place has to be adapted to handle the
>>>> new ARCH value.
>>>>
>>>> Please push this right to http://hg.openjdk.java.net/jdk9/hs/hotspot
>>>> in order to get it into http://hg.openjdk.java.net/jdk9/dev/hotspot
>>>> together with 8046471.
>>>>
>>>> Note: this change depends on 8046471 in the hotspot AND in the
>>>> top-level directory!
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>
>>>
>>
From frederic.parain at oracle.com Mon Jun 30 14:27:11 2014
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 30 Jun 2014 16:27:11 +0200
Subject: RFR 8047737 Move array component mirror to instance of
java/lang/Class
In-Reply-To: <53B15B50.6070405@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
<53B15B50.6070405@oracle.com>
Message-ID: <53B173BF.2060604@oracle.com>
On 30/06/2014 14:42, Coleen Phillimore wrote:
>
> On 6/30/14, 1:55 AM, David Holmes wrote:
>> Hi Coleen,
>>
>> Your webrev links are to internal locations.
>
> Sorry, I cut/pasted the wrong links. They are:
>
> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
First step looks good.
> and the full version
>
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
The correct link to the full version seems to be:
http://cr.openjdk.java.net/~coleenp/8047737_hotspot_full/
I haven't reviewed the full version yet.
Fred
> Thank you for pointing this out David.
>
> Coleen
>
>>
>> David
>>
>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>> processing and intrinsics in JVM
>>>
>>> This is part of ongoing work to clean up oop pointers in the metadata
>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>> performance benefit at the end of all of this if we can remove all oop
>>> pointers from metadata. mirror in Klass is the only one left after
>>> this full change.
>>>
>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>
>>> There are a couple steps to this change because Hotspot testing is done
>>> with promoted JDKs. The first step is this webrev:
>>>
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>
>>> When the JDK is promoted, the code to remove
>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>
>>> Finally, a compatibility request and licensee notification will occur to
>>> remove the function JVM_GetComponentType.
>>>
>>> Performance testing was done that shows no difference in performance.
>>> The isArray() call is a compiler intrinsic which is now called instead
>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>
>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>> tests were performed on both the change requested (1st one) and the full
>>> change.
>>>
>>> hotspot NSK tests were run on the hotspot-only change with a promoted
>>> JDK.
>>>
>>> Please send your comments.
>>>
>>> Thanks,
>>> Coleen
>
--
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com
From coleen.phillimore at oracle.com Mon Jun 30 14:30:56 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 10:30:56 -0400
Subject: RFR 8047737 Move array component mirror to instance of
java/lang/Class
In-Reply-To: <53B173BF.2060604@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
<53B15B50.6070405@oracle.com> <53B173BF.2060604@oracle.com>
Message-ID: <53B174A0.1050409@oracle.com>
Thank you, Fred, and thanks for correcting the link below.
Coleen
On 6/30/14, 10:27 AM, Frederic Parain wrote:
>
>
> On 30/06/2014 14:42, Coleen Phillimore wrote:
>>
>> On 6/30/14, 1:55 AM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> Your webrev links are to internal locations.
>>
>> Sorry, I cut/pasted the wrong links. They are:
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>
> First step looks good.
>
>> and the full version
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>
> The correct link to the full version seems to be:
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot_full/
>
> I haven't reviewed the full version yet.
>
> Fred
>
>> Thank you for pointing this out David.
>>
>> Coleen
>>
>>>
>>> David
>>>
>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>>> Summary: Add field in java.lang.Class for componentType to simplify
>>>> oop
>>>> processing and intrinsics in JVM
>>>>
>>>> This is part of ongoing work to clean up oop pointers in the metadata
>>>> and simplify the interface between the JDK j.l.C and the JVM.
>>>> There's a
>>>> performance benefit at the end of all of this if we can remove all oop
>>>> pointers from metadata. mirror in Klass is the only one left after
>>>> this full change.
>>>>
>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>>
>>>> There are a couple steps to this change because Hotspot testing is
>>>> done
>>>> with promoted JDKs. The first step is this webrev:
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>>
>>>> When the JDK is promoted, the code to remove
>>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>>
>>>> Finally, a compatibility request and licensee notification will
>>>> occur to
>>>> remove the function JVM_GetComponentType.
>>>>
>>>> Performance testing was done that shows no difference in performance.
>>>> The isArray() call is a compiler intrinsic which is now called instead
>>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>>
>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>>> tests were performed on both the change requested (1st one) and the
>>>> full
>>>> change.
>>>>
>>>> hotspot NSK tests were run on the hotspot-only change with a promoted
>>>> JDK.
>>>>
>>>> Please send your comments.
>>>>
>>>> Thanks,
>>>> Coleen
>>
>
From christian.thalinger at oracle.com Mon Jun 30 14:58:50 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 30 Jun 2014 07:58:50 -0700
Subject: [9] RFR(XS): 8007987: ciConstantPoolCache::_keys should be array
of 32bit int
In-Reply-To: <53B10282.3070202@oracle.com>
References: <53AC1827.6060601@oracle.com> <C28E4D73-7B9E-44B7-88FD-023C14D4C956@oracle.com> <53AC43FE.7080705@oracle.com>
<53AD16C8.9020000@oracle.com> <53B10282.3070202@oracle.com>
Message-ID: <95EE45C1-AE0E-4B16-ADAC-B85634F822AF@oracle.com>
You can push this.
On Jun 29, 2014, at 11:24 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> Hi,
>
> can we push this one or do I need another review?
>
> Thanks,
> Tobias
>
> On 27.06.2014 09:01, Tobias Hartmann wrote:
>> Hi Coleen,
>>
>> thanks for the review.
>>
>>>> // ciConstantPoolCache
>>>> //
>>>> // The class caches indexed constant pool lookups.
>>>> //
>>>> // Usage note: this klass has nothing to do with ConstantPoolCache*.
>>> Oh my gosh.
>>
>> Yes, that comment is a little bit confusing.
>>
>>> If _keys corresponds to constant pool indices then an int is enough to store the values, so this looks ok. The ConstantPool length is a u2 but an int is better to future-proof this.
>>
>> I think so too.
>>
>> Thanks,
>> Tobias
>>
>>>
>>> Coleen
>>>
>>> On 6/26/14, 10:42 AM, Christian Thalinger wrote:
>>>> Can you also have someone from the runtime team to take a quick look? Sending to hotspot-dev instead.
>>>>
>>>> On Jun 26, 2014, at 5:55 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> please review the following small patch that changes the type of the keys stored in the array from intptr_t to int. This is sufficient to store the 2 byte constant pool indexes and conforms to the interface where int is used.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8007987
>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8007987/webrev.00/
>>>>> Testing: JPRT
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>
>>
>
From coleen.phillimore at oracle.com Mon Jun 30 15:40:18 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 11:40:18 -0400
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com> <53B11765.1020107@oracle.com>
<CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com>
Message-ID: <53B184E2.5020700@oracle.com>
Volker,
This is a nice cleanup! Thank you. I've reviewed it. Since it's based
on hs-gc, I think someone from the gc group should sponsor it.
Otherwise, I'd be happy to.
One small comment below.
On 6/30/14, 10:25 AM, Volker Simonis wrote:
> Hi David,
>
> thanks for looking at the change. Please find my answers inline
>
> On Mon, Jun 30, 2014 at 9:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Volker,
>>
>> Two minor queries:
>>
>> src/share/vm/interpreter/bytecodeInterpreter.cpp
>>
>> + (int)(istate->bcp() - METHOD->code_base()),
>>
>> Not clear that this is an int result - what type are the operands?
> The operands are both 'address' (aka 'char*') so the actual result
> type would be 'ptrdiff_t'. But at this place, we subtract the code
> base from the current byte code pointer the result of which should be
> a short integer. I therefore think the cast should be OK.
>
>> + tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
>> this->_oop_temp);
>>
>> uintptr_t or intptr_t ? (Yes I see the existing code has the same mismatch
>> but I don't understand why.)
> This code is there since the first OpenJDK checkin and as fas as I can
> see it was added with 6u10.
>
> I think it's just the name INTPTR_FORMAT which is a little misleading.
> Actually INTPTR_FORMAT is defined as:
>
> #ifdef _LP64
> #define INTPTR_FORMAT "0x%016" PRIxPTR
> #define PTR_FORMAT "0x%016" PRIxPTR
> #else // !_LP64
> #define INTPTR_FORMAT "0x%08" PRIxPTR
> #define PTR_FORMAT "0x%08" PRIxPTR
> #endif // _LP64
>
> in globalDefinitions.hpp and "PRIxPTR" is the specifier for printing
> an "uintptr_t" (as defined in inttypes.h by C99).
>
> Strictly speaking, I think INTPTR_FORMAT should really be defined to
> PRIiPTR (or PRIdPTR) which could then be used to output signed values.
> On the other hand PTR_FORMAT should be used in the code only for
> printing unsigned hex values. But there are currently hundreds of
> places where INTPTR_FORMAT is used for printing unsigned hex values so
> that would be another XXL change.
This PRIxPTR symbolically doesn't mean anything to me (PRI means
"print"?) and I'm not anxious to review another XXL change like this.
We should decide on some sort of migration plan for this that is easily
followed. I thought INTPTR_FORMAT was supposed to print unsigned hex
values because pointers are unsigned.
Thanks,
Coleen
> Regards,
> Volker
>
>> David
>> -----
>>
>>
>> On 28/06/2014 2:20 AM, Volker Simonis wrote:
>>> Hi,
>>>
>>> this is a follow-up for change "8037816: Fix for 8036122 breaks build
>>> with Xcode5/clang". It fixes the matching of format string parameter
>>> types to the actual argument types for the PPC64 and CPP-Interpreter
>>> files in the same way as 8037816 already did it for all the other
>>> files (so mainly insertions of 'p2i()' calls and some manual casts).
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
>>> https://bugs.openjdk.java.net/browse/JDK-8048169
>>>
>>> This change only touches PPC64 and the two CPP-Interpreter files
>>> src/share/vm/interpreter/bytecodeInterpreter.cpp and
>>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>>>
>>> Please review and sponsor.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
From stefan.karlsson at oracle.com Mon Jun 30 15:50:20 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 30 Jun 2014 17:50:20 +0200
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <53B184E2.5020700@oracle.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com> <53B11765.1020107@oracle.com> <CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com>
<53B184E2.5020700@oracle.com>
Message-ID: <53B1873C.5040907@oracle.com>
On 2014-06-30 17:40, Coleen Phillimore wrote:
>
> Volker,
> This is a nice cleanup! Thank you. I've reviewed it. Since it's
> based on hs-gc, I think someone from the gc group should sponsor it.
> Otherwise, I'd be happy to.
This is based on jdk9/hs/hotspot:
"Compare against: http://hg.openjdk.java.net/jdk9/hs/hotspot"
so feel free to sponsor this change.
thanks,
StefanK
>
> One small comment below.
>
> On 6/30/14, 10:25 AM, Volker Simonis wrote:
>> Hi David,
>>
>> thanks for looking at the change. Please find my answers inline
>>
>> On Mon, Jun 30, 2014 at 9:53 AM, David Holmes
>> <david.holmes at oracle.com> wrote:
>>> Hi Volker,
>>>
>>> Two minor queries:
>>>
>>> src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>
>>> + (int)(istate->bcp() - METHOD->code_base()),
>>>
>>> Not clear that this is an int result - what type are the operands?
>> The operands are both 'address' (aka 'char*') so the actual result
>> type would be 'ptrdiff_t'. But at this place, we subtract the code
>> base from the current byte code pointer the result of which should be
>> a short integer. I therefore think the cast should be OK.
>>
>>> + tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
>>> this->_oop_temp);
>>>
>>> uintptr_t or intptr_t ? (Yes I see the existing code has the same
>>> mismatch
>>> but I don't understand why.)
>> This code is there since the first OpenJDK checkin and as fas as I can
>> see it was added with 6u10.
>>
>> I think it's just the name INTPTR_FORMAT which is a little misleading.
>> Actually INTPTR_FORMAT is defined as:
>>
>> #ifdef _LP64
>> #define INTPTR_FORMAT "0x%016" PRIxPTR
>> #define PTR_FORMAT "0x%016" PRIxPTR
>> #else // !_LP64
>> #define INTPTR_FORMAT "0x%08" PRIxPTR
>> #define PTR_FORMAT "0x%08" PRIxPTR
>> #endif // _LP64
>>
>> in globalDefinitions.hpp and "PRIxPTR" is the specifier for printing
>> an "uintptr_t" (as defined in inttypes.h by C99).
>>
>> Strictly speaking, I think INTPTR_FORMAT should really be defined to
>> PRIiPTR (or PRIdPTR) which could then be used to output signed values.
>> On the other hand PTR_FORMAT should be used in the code only for
>> printing unsigned hex values. But there are currently hundreds of
>> places where INTPTR_FORMAT is used for printing unsigned hex values so
>> that would be another XXL change.
>
> This PRIxPTR symbolically doesn't mean anything to me (PRI means
> "print"?) and I'm not anxious to review another XXL change like
> this. We should decide on some sort of migration plan for this that
> is easily followed. I thought INTPTR_FORMAT was supposed to print
> unsigned hex values because pointers are unsigned.
>
> Thanks,
> Coleen
>
>
>> Regards,
>> Volker
>>
>>> David
>>> -----
>>>
>>>
>>> On 28/06/2014 2:20 AM, Volker Simonis wrote:
>>>> Hi,
>>>>
>>>> this is a follow-up for change "8037816: Fix for 8036122 breaks build
>>>> with Xcode5/clang". It fixes the matching of format string parameter
>>>> types to the actual argument types for the PPC64 and CPP-Interpreter
>>>> files in the same way as 8037816 already did it for all the other
>>>> files (so mainly insertions of 'p2i()' calls and some manual casts).
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
>>>> https://bugs.openjdk.java.net/browse/JDK-8048169
>>>>
>>>> This change only touches PPC64 and the two CPP-Interpreter files
>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp and
>>>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>>>>
>>>> Please review and sponsor.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>
From volker.simonis at gmail.com Mon Jun 30 15:54:46 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 30 Jun 2014 17:54:46 +0200
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <53B1873C.5040907@oracle.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com>
<53B11765.1020107@oracle.com>
<CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com>
<53B184E2.5020700@oracle.com> <53B1873C.5040907@oracle.com>
Message-ID: <CA+3eh1393DcCfteG+6xv5hddhoU9GPZcyOo8kNdSS_CmvOdY8Q@mail.gmail.com>
On Mon, Jun 30, 2014 at 5:50 PM, Stefan Karlsson
<stefan.karlsson at oracle.com> wrote:
> On 2014-06-30 17:40, Coleen Phillimore wrote:
>>
>>
>> Volker,
>> This is a nice cleanup! Thank you. I've reviewed it. Since it's based
>> on hs-gc, I think someone from the gc group should sponsor it. Otherwise,
>> I'd be happy to.
>
>
> This is based on jdk9/hs/hotspot:
> "Compare against: http://hg.openjdk.java.net/jdk9/hs/hotspot"
>
The initial, offending change was in hs-gc but because it has already
propagated to all the other hs repos I intentionally did this fix-up
change in jdk9/hs/hotspot to get it into the other ones as fast as
possible.
> so feel free to sponsor this change.
>
Would be great.
Thanks,
Volker
> thanks,
> StefanK
>
>
>>
>> One small comment below.
>>
>> On 6/30/14, 10:25 AM, Volker Simonis wrote:
>>>
>>> Hi David,
>>>
>>> thanks for looking at the change. Please find my answers inline
>>>
>>> On Mon, Jun 30, 2014 at 9:53 AM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> Two minor queries:
>>>>
>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>>
>>>> + (int)(istate->bcp() - METHOD->code_base()),
>>>>
>>>> Not clear that this is an int result - what type are the operands?
>>>
>>> The operands are both 'address' (aka 'char*') so the actual result
>>> type would be 'ptrdiff_t'. But at this place, we subtract the code
>>> base from the current byte code pointer the result of which should be
>>> a short integer. I therefore think the cast should be OK.
>>>
>>>> + tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
>>>> this->_oop_temp);
>>>>
>>>> uintptr_t or intptr_t ? (Yes I see the existing code has the same
>>>> mismatch
>>>> but I don't understand why.)
>>>
>>> This code is there since the first OpenJDK checkin and as fas as I can
>>> see it was added with 6u10.
>>>
>>> I think it's just the name INTPTR_FORMAT which is a little misleading.
>>> Actually INTPTR_FORMAT is defined as:
>>>
>>> #ifdef _LP64
>>> #define INTPTR_FORMAT "0x%016" PRIxPTR
>>> #define PTR_FORMAT "0x%016" PRIxPTR
>>> #else // !_LP64
>>> #define INTPTR_FORMAT "0x%08" PRIxPTR
>>> #define PTR_FORMAT "0x%08" PRIxPTR
>>> #endif // _LP64
>>>
>>> in globalDefinitions.hpp and "PRIxPTR" is the specifier for printing
>>> an "uintptr_t" (as defined in inttypes.h by C99).
>>>
>>> Strictly speaking, I think INTPTR_FORMAT should really be defined to
>>> PRIiPTR (or PRIdPTR) which could then be used to output signed values.
>>> On the other hand PTR_FORMAT should be used in the code only for
>>> printing unsigned hex values. But there are currently hundreds of
>>> places where INTPTR_FORMAT is used for printing unsigned hex values so
>>> that would be another XXL change.
>>
>>
>> This PRIxPTR symbolically doesn't mean anything to me (PRI means "print"?)
>> and I'm not anxious to review another XXL change like this. We should
>> decide on some sort of migration plan for this that is easily followed. I
>> thought INTPTR_FORMAT was supposed to print unsigned hex values because
>> pointers are unsigned.
>>
>> Thanks,
>> Coleen
>>
>>
>>> Regards,
>>> Volker
>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>> On 28/06/2014 2:20 AM, Volker Simonis wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> this is a follow-up for change "8037816: Fix for 8036122 breaks build
>>>>> with Xcode5/clang". It fixes the matching of format string parameter
>>>>> types to the actual argument types for the PPC64 and CPP-Interpreter
>>>>> files in the same way as 8037816 already did it for all the other
>>>>> files (so mainly insertions of 'p2i()' calls and some manual casts).
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8048169
>>>>>
>>>>> This change only touches PPC64 and the two CPP-Interpreter files
>>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp and
>>>>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>>>>>
>>>>> Please review and sponsor.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>
>
From coleen.phillimore at oracle.com Mon Jun 30 16:15:30 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 12:15:30 -0400
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <CA+3eh1393DcCfteG+6xv5hddhoU9GPZcyOo8kNdSS_CmvOdY8Q@mail.gmail.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com> <53B11765.1020107@oracle.com> <CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com> <53B184E2.5020700@oracle.com> <53B1873C.5040907@oracle.com>
<CA+3eh1393DcCfteG+6xv5hddhoU9GPZcyOo8kNdSS_CmvOdY8Q@mail.gmail.com>
Message-ID: <53B18D22.1050305@oracle.com>
I replied to the wrong RFR. This one looks fine also. Let me warn
Alejandro that this would go straight to hs main (which I think is what
we are deciding).
Coleen
On 6/30/14, 11:54 AM, Volker Simonis wrote:
> On Mon, Jun 30, 2014 at 5:50 PM, Stefan Karlsson
> <stefan.karlsson at oracle.com> wrote:
>> On 2014-06-30 17:40, Coleen Phillimore wrote:
>>>
>>> Volker,
>>> This is a nice cleanup! Thank you. I've reviewed it. Since it's based
>>> on hs-gc, I think someone from the gc group should sponsor it. Otherwise,
>>> I'd be happy to.
>>
>> This is based on jdk9/hs/hotspot:
>> "Compare against: http://hg.openjdk.java.net/jdk9/hs/hotspot"
>>
> The initial, offending change was in hs-gc but because it has already
> propagated to all the other hs repos I intentionally did this fix-up
> change in jdk9/hs/hotspot to get it into the other ones as fast as
> possible.
>
>> so feel free to sponsor this change.
>>
> Would be great.
>
> Thanks,
> Volker
>
>> thanks,
>> StefanK
>>
>>
>>> One small comment below.
>>>
>>> On 6/30/14, 10:25 AM, Volker Simonis wrote:
>>>> Hi David,
>>>>
>>>> thanks for looking at the change. Please find my answers inline
>>>>
>>>> On Mon, Jun 30, 2014 at 9:53 AM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>> Hi Volker,
>>>>>
>>>>> Two minor queries:
>>>>>
>>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>>>
>>>>> + (int)(istate->bcp() - METHOD->code_base()),
>>>>>
>>>>> Not clear that this is an int result - what type are the operands?
>>>> The operands are both 'address' (aka 'char*') so the actual result
>>>> type would be 'ptrdiff_t'. But at this place, we subtract the code
>>>> base from the current byte code pointer the result of which should be
>>>> a short integer. I therefore think the cast should be OK.
>>>>
>>>>> + tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
>>>>> this->_oop_temp);
>>>>>
>>>>> uintptr_t or intptr_t ? (Yes I see the existing code has the same
>>>>> mismatch
>>>>> but I don't understand why.)
>>>> This code is there since the first OpenJDK checkin and as fas as I can
>>>> see it was added with 6u10.
>>>>
>>>> I think it's just the name INTPTR_FORMAT which is a little misleading.
>>>> Actually INTPTR_FORMAT is defined as:
>>>>
>>>> #ifdef _LP64
>>>> #define INTPTR_FORMAT "0x%016" PRIxPTR
>>>> #define PTR_FORMAT "0x%016" PRIxPTR
>>>> #else // !_LP64
>>>> #define INTPTR_FORMAT "0x%08" PRIxPTR
>>>> #define PTR_FORMAT "0x%08" PRIxPTR
>>>> #endif // _LP64
>>>>
>>>> in globalDefinitions.hpp and "PRIxPTR" is the specifier for printing
>>>> an "uintptr_t" (as defined in inttypes.h by C99).
>>>>
>>>> Strictly speaking, I think INTPTR_FORMAT should really be defined to
>>>> PRIiPTR (or PRIdPTR) which could then be used to output signed values.
>>>> On the other hand PTR_FORMAT should be used in the code only for
>>>> printing unsigned hex values. But there are currently hundreds of
>>>> places where INTPTR_FORMAT is used for printing unsigned hex values so
>>>> that would be another XXL change.
>>>
>>> This PRIxPTR symbolically doesn't mean anything to me (PRI means "print"?)
>>> and I'm not anxious to review another XXL change like this. We should
>>> decide on some sort of migration plan for this that is easily followed. I
>>> thought INTPTR_FORMAT was supposed to print unsigned hex values because
>>> pointers are unsigned.
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>> On 28/06/2014 2:20 AM, Volker Simonis wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this is a follow-up for change "8037816: Fix for 8036122 breaks build
>>>>>> with Xcode5/clang". It fixes the matching of format string parameter
>>>>>> types to the actual argument types for the PPC64 and CPP-Interpreter
>>>>>> files in the same way as 8037816 already did it for all the other
>>>>>> files (so mainly insertions of 'p2i()' calls and some manual casts).
>>>>>>
>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8048169
>>>>>>
>>>>>> This change only touches PPC64 and the two CPP-Interpreter files
>>>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp and
>>>>>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>>>>>>
>>>>>> Please review and sponsor.
>>>>>>
>>>>>> Thank you and best regards,
>>>>>> Volker
>>>>>>
From volker.simonis at gmail.com Mon Jun 30 16:18:22 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 30 Jun 2014 18:18:22 +0200
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <53B184E2.5020700@oracle.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com>
<53B11765.1020107@oracle.com>
<CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com>
<53B184E2.5020700@oracle.com>
Message-ID: <CA+3eh127rLk+WGpUaCjupDaeNHnhdMY8F=5_-UnAqJ1eMF2JTA@mail.gmail.com>
Hi Coleen,
thanks for the review. As far as I have found out, these are macros
for printf and scanf format specifiers as defined by C99. I don't know
why we have both, INTPTR_FORMAT and PTR_FORMAT defined to the same
format specifier. Currently, I found 1001 occurences of INTPTR_FORMAT
and 845 occurences of PTR_FORMAT. They could be probably unified to
one macro as they already are the same now anyway.
As far as I can see, we had:
#ifdef _LP64
#define PTR_FORMAT PTR64_FORMAT
#else // !_LP64
#define PTR_FORMAT PTR32_FORMAT
#endif // _LP64
#define INTPTR_FORMAT PTR_FORMAT
before the big "7089790: integrate bsd-port changes" change which
changed this to the current version. Seems like INTPTR_FORMAT has
always just been a short cut (which is actually longer!) for
PTR_FORMAT:)
Regards,
Volker
On Mon, Jun 30, 2014 at 5:40 PM, Coleen Phillimore
<coleen.phillimore at oracle.com> wrote:
>
> Volker,
> This is a nice cleanup! Thank you. I've reviewed it. Since it's based on
> hs-gc, I think someone from the gc group should sponsor it. Otherwise, I'd
> be happy to.
>
> One small comment below.
>
>
> On 6/30/14, 10:25 AM, Volker Simonis wrote:
>>
>> Hi David,
>>
>> thanks for looking at the change. Please find my answers inline
>>
>> On Mon, Jun 30, 2014 at 9:53 AM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> Hi Volker,
>>>
>>> Two minor queries:
>>>
>>> src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>
>>> + (int)(istate->bcp() - METHOD->code_base()),
>>>
>>> Not clear that this is an int result - what type are the operands?
>>
>> The operands are both 'address' (aka 'char*') so the actual result
>> type would be 'ptrdiff_t'. But at this place, we subtract the code
>> base from the current byte code pointer the result of which should be
>> a short integer. I therefore think the cast should be OK.
>>
>>> + tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
>>> this->_oop_temp);
>>>
>>> uintptr_t or intptr_t ? (Yes I see the existing code has the same
>>> mismatch
>>> but I don't understand why.)
>>
>> This code is there since the first OpenJDK checkin and as fas as I can
>> see it was added with 6u10.
>>
>> I think it's just the name INTPTR_FORMAT which is a little misleading.
>> Actually INTPTR_FORMAT is defined as:
>>
>> #ifdef _LP64
>> #define INTPTR_FORMAT "0x%016" PRIxPTR
>> #define PTR_FORMAT "0x%016" PRIxPTR
>> #else // !_LP64
>> #define INTPTR_FORMAT "0x%08" PRIxPTR
>> #define PTR_FORMAT "0x%08" PRIxPTR
>> #endif // _LP64
>>
>> in globalDefinitions.hpp and "PRIxPTR" is the specifier for printing
>> an "uintptr_t" (as defined in inttypes.h by C99).
>>
>> Strictly speaking, I think INTPTR_FORMAT should really be defined to
>> PRIiPTR (or PRIdPTR) which could then be used to output signed values.
>> On the other hand PTR_FORMAT should be used in the code only for
>> printing unsigned hex values. But there are currently hundreds of
>> places where INTPTR_FORMAT is used for printing unsigned hex values so
>> that would be another XXL change.
>
>
> This PRIxPTR symbolically doesn't mean anything to me (PRI means "print"?)
> and I'm not anxious to review another XXL change like this. We should
> decide on some sort of migration plan for this that is easily followed. I
> thought INTPTR_FORMAT was supposed to print unsigned hex values because
> pointers are unsigned.
>
> Thanks,
> Coleen
>
>
>
>> Regards,
>> Volker
>>
>>> David
>>> -----
>>>
>>>
>>> On 28/06/2014 2:20 AM, Volker Simonis wrote:
>>>>
>>>> Hi,
>>>>
>>>> this is a follow-up for change "8037816: Fix for 8036122 breaks build
>>>> with Xcode5/clang". It fixes the matching of format string parameter
>>>> types to the actual argument types for the PPC64 and CPP-Interpreter
>>>> files in the same way as 8037816 already did it for all the other
>>>> files (so mainly insertions of 'p2i()' calls and some manual casts).
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
>>>> https://bugs.openjdk.java.net/browse/JDK-8048169
>>>>
>>>> This change only touches PPC64 and the two CPP-Interpreter files
>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp and
>>>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>>>>
>>>> Please review and sponsor.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>
From coleen.phillimore at oracle.com Mon Jun 30 16:19:36 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 12:19:36 -0400
Subject: RFR (M): 8048241: Introduce umbrella header os.inline.hpp and
clean up includes
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CED7FF4@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CED7FF4@DEWDFEMB12A.global.corp.sap>
Message-ID: <53B18E18.80707@oracle.com>
Goetz,
I reviewed this change and it looks great. Thank you for cleaning this
up. Since it's based on hs-gc repository, I think someone from the GC
group should sponsor. Otherwise, I'd be happy to.
Thanks!
Coleen
(this was my reply to another RFR, sorry)
On 6/29/14, 5:00 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> This change adds a new header os.inline.hpp including the os_<os>.include.hpp
> headers. This allows to remove around 30 os dependent include cascades, some of
> them even without adding the os.inline.hpp header in that file.
> Also, os.inline.hpp is added in several files that call functions from these
> headers where it was missing so far.
>
> Some further cleanups:
> OrderAccess include in adaptiveFreeList.cpp is needed because of freeChunk.hpp.
>
> The include of os.inline.hpp in thread.inline.hpp is needed because
> Thread::current() uses thread() from ThreadLocalStorage, which again uses
> os::thread_local_storage_at which is implemented platform dependent.
>
> I moved some methods without dependencies to other .include.hpp files
> to os_windows.hpp/os_posix.hpp. This reduces the need for os.inline.hpp
> includes a lot.
>
> Please review and test this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/webrevs/8048241-osInc/webrev.00/
>
> I compiled and tested this without precompiled headers on linuxx86_64,
> linuxppc64, windowsx86_64, solaris_sparc64, solaris_sparc32, darwinx86_64,
> aixppc64 in opt, dbg and fastdbg versions.
>
> Thanks and best regards,
> Goetz.
From coleen.phillimore at oracle.com Mon Jun 30 16:26:19 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 12:26:19 -0400
Subject: RFR(M/S): 8048169: Change 8037816 breaks HS build on PPC64 and
CPP-Interpreter platforms
In-Reply-To: <CA+3eh127rLk+WGpUaCjupDaeNHnhdMY8F=5_-UnAqJ1eMF2JTA@mail.gmail.com>
References: <CA+3eh12yXGTn7MnvVPOLy8Y0W9LK8=3-ZfEOBLpfAg=F7GTqNA@mail.gmail.com> <53B11765.1020107@oracle.com> <CA+3eh11KcJGdYaOMXYUnLF2FRzghN=3S-6My6FkNK7U=Lwo5AA@mail.gmail.com> <53B184E2.5020700@oracle.com>
<CA+3eh127rLk+WGpUaCjupDaeNHnhdMY8F=5_-UnAqJ1eMF2JTA@mail.gmail.com>
Message-ID: <53B18FAB.1080601@oracle.com>
My first impulse has been to use INTPTR_FORMAT unless the compiler
complains. David Chase and others are trying to make this sane though,
I am hoping it turns out something I can remember not to break. :)
Thanks,
Coleen
On 6/30/14, 12:18 PM, Volker Simonis wrote:
> Hi Coleen,
>
> thanks for the review. As far as I have found out, these are macros
> for printf and scanf format specifiers as defined by C99. I don't know
> why we have both, INTPTR_FORMAT and PTR_FORMAT defined to the same
> format specifier. Currently, I found 1001 occurences of INTPTR_FORMAT
> and 845 occurences of PTR_FORMAT. They could be probably unified to
> one macro as they already are the same now anyway.
>
> As far as I can see, we had:
>
> #ifdef _LP64
> #define PTR_FORMAT PTR64_FORMAT
> #else // !_LP64
> #define PTR_FORMAT PTR32_FORMAT
> #endif // _LP64
>
> #define INTPTR_FORMAT PTR_FORMAT
>
> before the big "7089790: integrate bsd-port changes" change which
> changed this to the current version. Seems like INTPTR_FORMAT has
> always just been a short cut (which is actually longer!) for
> PTR_FORMAT:)
>
> Regards,
> Volker
>
> On Mon, Jun 30, 2014 at 5:40 PM, Coleen Phillimore
> <coleen.phillimore at oracle.com> wrote:
>> Volker,
>> This is a nice cleanup! Thank you. I've reviewed it. Since it's based on
>> hs-gc, I think someone from the gc group should sponsor it. Otherwise, I'd
>> be happy to.
>>
>> One small comment below.
>>
>>
>> On 6/30/14, 10:25 AM, Volker Simonis wrote:
>>> Hi David,
>>>
>>> thanks for looking at the change. Please find my answers inline
>>>
>>> On Mon, Jun 30, 2014 at 9:53 AM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>> Hi Volker,
>>>>
>>>> Two minor queries:
>>>>
>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>>
>>>> + (int)(istate->bcp() - METHOD->code_base()),
>>>>
>>>> Not clear that this is an int result - what type are the operands?
>>> The operands are both 'address' (aka 'char*') so the actual result
>>> type would be 'ptrdiff_t'. But at this place, we subtract the code
>>> base from the current byte code pointer the result of which should be
>>> a short integer. I therefore think the cast should be OK.
>>>
>>>> + tty->print_cr("native_mirror: " INTPTR_FORMAT, (uintptr_t)
>>>> this->_oop_temp);
>>>>
>>>> uintptr_t or intptr_t ? (Yes I see the existing code has the same
>>>> mismatch
>>>> but I don't understand why.)
>>> This code is there since the first OpenJDK checkin and as fas as I can
>>> see it was added with 6u10.
>>>
>>> I think it's just the name INTPTR_FORMAT which is a little misleading.
>>> Actually INTPTR_FORMAT is defined as:
>>>
>>> #ifdef _LP64
>>> #define INTPTR_FORMAT "0x%016" PRIxPTR
>>> #define PTR_FORMAT "0x%016" PRIxPTR
>>> #else // !_LP64
>>> #define INTPTR_FORMAT "0x%08" PRIxPTR
>>> #define PTR_FORMAT "0x%08" PRIxPTR
>>> #endif // _LP64
>>>
>>> in globalDefinitions.hpp and "PRIxPTR" is the specifier for printing
>>> an "uintptr_t" (as defined in inttypes.h by C99).
>>>
>>> Strictly speaking, I think INTPTR_FORMAT should really be defined to
>>> PRIiPTR (or PRIdPTR) which could then be used to output signed values.
>>> On the other hand PTR_FORMAT should be used in the code only for
>>> printing unsigned hex values. But there are currently hundreds of
>>> places where INTPTR_FORMAT is used for printing unsigned hex values so
>>> that would be another XXL change.
>>
>> This PRIxPTR symbolically doesn't mean anything to me (PRI means "print"?)
>> and I'm not anxious to review another XXL change like this. We should
>> decide on some sort of migration plan for this that is easily followed. I
>> thought INTPTR_FORMAT was supposed to print unsigned hex values because
>> pointers are unsigned.
>>
>> Thanks,
>> Coleen
>>
>>
>>
>>> Regards,
>>> Volker
>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>> On 28/06/2014 2:20 AM, Volker Simonis wrote:
>>>>> Hi,
>>>>>
>>>>> this is a follow-up for change "8037816: Fix for 8036122 breaks build
>>>>> with Xcode5/clang". It fixes the matching of format string parameter
>>>>> types to the actual argument types for the PPC64 and CPP-Interpreter
>>>>> files in the same way as 8037816 already did it for all the other
>>>>> files (so mainly insertions of 'p2i()' calls and some manual casts).
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8048169/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8048169
>>>>>
>>>>> This change only touches PPC64 and the two CPP-Interpreter files
>>>>> src/share/vm/interpreter/bytecodeInterpreter.cpp and
>>>>> src/share/vm/interpreter/bytecodeInterpreterProfiling.hpp
>>>>>
>>>>> Please review and sponsor.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
From christian.thalinger at oracle.com Mon Jun 30 19:50:47 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 30 Jun 2014 12:50:47 -0700
Subject: RFR 8047737 Move array component mirror to instance of
java/lang/Class
In-Reply-To: <53B15B50.6070405@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
<53B15B50.6070405@oracle.com>
Message-ID: <E5F1C1EF-1D1C-40AE-8006-C56254791FA2@oracle.com>
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The initialization value of non-null
// prevents future JIT optimizations from assuming this final field is null.
classLoader = loader;
+ componentType = null;
}
Are we worried about the same optimization?
+ compute_optional_offset(_component_mirror_offset,
+ klass_oop, vmSymbols::componentType_name(),
+ vmSymbols::class_signature());
Is there a followup cleanup to make it non-optional? Or, are you waiting for JPRT to be able to push hotspot and jdk changes together?
On Jun 30, 2014, at 5:42 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
> On 6/30/14, 1:55 AM, David Holmes wrote:
>> Hi Coleen,
>>
>> Your webrev links are to internal locations.
>
> Sorry, I cut/pasted the wrong links. They are:
>
> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>
> and the full version
>
> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>
> Thank you for pointing this out David.
>
> Coleen
>
>>
>> David
>>
>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>> processing and intrinsics in JVM
>>>
>>> This is part of ongoing work to clean up oop pointers in the metadata
>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>> performance benefit at the end of all of this if we can remove all oop
>>> pointers from metadata. mirror in Klass is the only one left after
>>> this full change.
>>>
>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>
>>> There are a couple steps to this change because Hotspot testing is done
>>> with promoted JDKs. The first step is this webrev:
>>>
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>
>>> When the JDK is promoted, the code to remove
>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>
>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>
>>> Finally, a compatibility request and licensee notification will occur to
>>> remove the function JVM_GetComponentType.
>>>
>>> Performance testing was done that shows no difference in performance.
>>> The isArray() call is a compiler intrinsic which is now called instead
>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>
>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>> tests were performed on both the change requested (1st one) and the full
>>> change.
>>>
>>> hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
>>>
>>> Please send your comments.
>>>
>>> Thanks,
>>> Coleen
>
From coleen.phillimore at oracle.com Mon Jun 30 20:06:39 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jun 2014 16:06:39 -0400
Subject: RFR 8047737 Move array component mirror to instance of
java/lang/Class
In-Reply-To: <E5F1C1EF-1D1C-40AE-8006-C56254791FA2@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
<53B15B50.6070405@oracle.com>
<E5F1C1EF-1D1C-40AE-8006-C56254791FA2@oracle.com>
Message-ID: <53B1C34F.5060901@oracle.com>
On 6/30/14, 3:50 PM, Christian Thalinger wrote:
> private Class(ClassLoader loader) {
> // Initialize final field for classLoader. The initialization value of non-null
> // prevents future JIT optimizations from assuming this final field is null.
> classLoader = loader;
> + componentType = null;
> }
>
> Are we worried about the same optimization?
I don't know if I was justified in worrying about the optimization in
the first place. Since getComponentType() is conditional, I wasn't
worried.
But it should be consistent. Maybe I should revert the classLoader
constructor change, now that I fixed all the tests not to care. What do
people think?
>
> + compute_optional_offset(_component_mirror_offset,
> + klass_oop, vmSymbols::componentType_name(),
> + vmSymbols::class_signature());
>
> Is there a followup cleanup to make it non-optional? Or, are you
> waiting for JPRT to be able to push hotspot and jdk changes together?
Yes, please look at the _full webrev. That has the non-optional changes
in it and the follow on changes to remove getComponentType as an
intrinsic in C2 (will file new RFE). I really would like a compiler
person to comment on it.
Thanks so much,
Coleen
>
> On Jun 30, 2014, at 5:42 AM, Coleen Phillimore
> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
> wrote:
>
>>
>> On 6/30/14, 1:55 AM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> Your webrev links are to internal locations.
>>
>> Sorry, I cut/pasted the wrong links. They are:
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
>> <http://cr.openjdk.java.net/%7Ecoleenp/8047737_jdk/>
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>
>> and the full version
>>
>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>
>> Thank you for pointing this out David.
>>
>> Coleen
>>
>>>
>>> David
>>>
>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>>> processing and intrinsics in JVM
>>>>
>>>> This is part of ongoing work to clean up oop pointers in the metadata
>>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>>> performance benefit at the end of all of this if we can remove all oop
>>>> pointers from metadata. mirror in Klass is the only one left after
>>>> this full change.
>>>>
>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>>
>>>> There are a couple steps to this change because Hotspot testing is done
>>>> with promoted JDKs. The first step is this webrev:
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>>
>>>> When the JDK is promoted, the code to remove
>>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>>
>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>>
>>>> Finally, a compatibility request and licensee notification will
>>>> occur to
>>>> remove the function JVM_GetComponentType.
>>>>
>>>> Performance testing was done that shows no difference in performance.
>>>> The isArray() call is a compiler intrinsic which is now called instead
>>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>>
>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>>> tests were performed on both the change requested (1st one) and the
>>>> full
>>>> change.
>>>>
>>>> hotspot NSK tests were run on the hotspot-only change with a
>>>> promoted JDK.
>>>>
>>>> Please send your comments.
>>>>
>>>> Thanks,
>>>> Coleen
>>
>
From serguei.spitsyn at oracle.com Mon Jun 30 21:09:13 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 30 Jun 2014 14:09:13 -0700
Subject: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed:
type check
In-Reply-To: <53AD310E.1010200@oracle.com>
References: <53AAD54E.8090804@oracle.com>
<53AC985D.6080806@oracle.com> <53AC9B80.9030805@oracle.com> <b0621477-b209-46db-8678-9b6a24cb87ce@default>
<53AD2C8F.9090702@oracle.com> <53AD310E.1010200@oracle.com>
Message-ID: <53B1D1F9.5050404@oracle.com>
Coleen, Vladimir and Markus,
Markus raised a good point on the predefined number of words reserved
for inlined mask storage.
I'm suggesting the following update:
diff -r 6b78c6948ec8 src/share/vm/interpreter/oopMapCache.hpp
--- a/src/share/vm/interpreter/oopMapCache.hpp Wed Jun 25 22:12:25 2014
+0000
+++ b/src/share/vm/interpreter/oopMapCache.hpp Mon Jun 30 14:02:17 2014
-0700
@@ -66,19 +66,15 @@ class InterpreterOopMap: ResourceObj {
public:
enum {
- N = 2, // the number of words reserved
+ N = 4, // the number of words reserved
// for inlined mask storage
small_mask_limit = N * BitsPerWord, // the maximum number of bits
// available for small masks,
// small_mask_limit can be
set to 0
// for testing bit_mask
allocation
The updated webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVMTI-lobj.2
Please, let me know if this update looks Ok.
Thanks,
Serguei
On 6/27/14 1:53 AM, serguei.spitsyn at oracle.com wrote:
> On 6/27/14 1:34 AM, serguei.spitsyn at oracle.com wrote:
>> Hi Markus,
>>
>> I raised a good point, thanks!
>
> Sorry, I wanted to say: "You raised a good point!" :)
>> What do you think about increasing the predefined size (N from 2 to 4)?
>>
>> 64 class InterpreterOopMap: ResourceObj {
>> 65 friend class OopMapCache;
>> 66
>> 67 public:
>> 68 enum {
>> 69 N = 2, // the number of words reserved
>> 70 // for inlined mask storage
>> 71 small_mask_limit = N * BitsPerWord, // the maximum number of bits
>> 72 // available for small masks,
>> 73 // small_mask_limit can be set to 0
>> 74 // for testing bit_mask allocation
>>
>>
>> Thanks,
>> Serguei
>>
>> On 6/27/14 1:12 AM, Markus Gr?nlund wrote:
>>> Hi Serguei,
>>>
>>>
>>> I am not convinced this is the right way to do this - by removing the #ifdef ENABLE_ZAP_DEAD_LOCALS" (which is an COMPILER2 specific #define under an ASSERT), we have now unconditionally increased the bitsize for every oopmap entry to two (compared to one previously) - the inlined oop_map bits_size cache is predefined to hold two words.
>>>
>>> This means the oopmap bitmap cache is effectively halved unconditionally.
>>>
>>> /Markus
>>>
>>>
>>> -----Original Message-----
>>> From: Serguei Spitsyn
>>> Sent: den 27 juni 2014 00:15
>>> To: Vladimir Ivanov;hotspot-dev at openjdk.java.net Developers;serviceability-dev at openjdk.java.net
>>> Subject: Re: RFR (S) 8013942: JSR 292: assert(type() == T_OBJECT) failed: type check
>>>
>>> Thanks, Vladimir!
>>> Serguei
>>>
>>> On 6/26/14 3:02 PM, Vladimir Ivanov wrote:
>>>> Looks good.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 6/25/14 5:57 PM,serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the fix for:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8013942
>>>>>
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8013942-JVM
>>>>> TI-lobj.1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>>
>>>>> This is a Nightly Stabilization issue.
>>>>>
>>>>> The problem is that the JVMTI GetLocalObject() function is hitting
>>>>> the assert
>>>>> as the type of the local at current bci is not T_OBJECT as expected.
>>>>> It is because this local is alive only in a narrow scope of one
>>>>> condition in the method but current bci is out of this csope.
>>>>>
>>>>> A fragment from the target method:
>>>>>
>>>>> static Class<?> canonicalize(Class<?> t, int how) {
>>>>> Class<?> ct; <== The local
>>>>> if (t == Object.class) {
>>>>> // no change, ever
>>>>> } else if (!t.isPrimitive()) {
>>>>> switch (how) {
>>>>> case UNWRAP:
>>>>> ct = Wrapper.asPrimitiveType(t); <== Initialized
>>>>> here
>>>>> if (ct != t) return ct;
>>>>> break;
>>>>> case RAW_RETURN:
>>>>> case ERASE:
>>>>> return Object.class;
>>>>> }
>>>>> } else if (t == void.class) { <== The
>>>>> GetLocalObject() is called with bci in this block
>>>>> // no change, usually
>>>>> switch (how) {
>>>>> case RAW_RETURN:
>>>>> return int.class;
>>>>> case WRAP:
>>>>> return Void.class;
>>>>> }
>>>>> } else {
>>>>> . . .
>>>>>
>>>>> The local 'ct' is only alive in the block of condition "if
>>>>> (!t.isPrimitive())".
>>>>> However, it is dead local in the next block.
>>>>>
>>>>> The fix suggested in the webrev above is to use the oop_mask for
>>>>> the method's current bci.
>>>>> It tells when the local is dead in the scope of this bci.
>>>>> Return the JVMTI_ERROR_INVALID_SLOT error in such a case.
>>>>>
>>>>> The fix also includes the tweeks which are necessary to enable the
>>>>> InterpreterOopMap.is_dead()
>>>>> function in the product mode as it was originally defined only
>>>>> under "#ifdef ENABLE_ZAP_DEAD_LOCALS".
>>>>> This makes the code in the oopMapCache.?pp a little bit more simple.
>>>>>
>>>>>
>>>>> Testing:
>>>>> Running the failing tests: vm.mlvm.indy.func.jvmti
>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp test runs on sparcv9 and
>>>>> amd64
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>
>
From christian.thalinger at oracle.com Mon Jun 30 22:09:34 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 30 Jun 2014 15:09:34 -0700
Subject: RFR 8047737 Move array component mirror to instance of
java/lang/Class
In-Reply-To: <53B1C34F.5060901@oracle.com>
References: <53ADC4D4.4030403@oracle.com> <53B0FBEF.5030607@oracle.com>
<53B15B50.6070405@oracle.com>
<E5F1C1EF-1D1C-40AE-8006-C56254791FA2@oracle.com>
<53B1C34F.5060901@oracle.com>
Message-ID: <EE19E3DB-2793-418C-8BB9-DF4B9BE894CD@oracle.com>
On Jun 30, 2014, at 1:06 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
> On 6/30/14, 3:50 PM, Christian Thalinger wrote:
>> private Class(ClassLoader loader) {
>> // Initialize final field for classLoader. The initialization value of non-null
>> // prevents future JIT optimizations from assuming this final field is null.
>> classLoader = loader;
>> + componentType = null;
>> }
>>
>> Are we worried about the same optimization?
>
> I don't know if I was justified in worrying about the optimization in the first place. Since getComponentType() is conditional, I wasn't worried.
>
> But it should be consistent. Maybe I should revert the classLoader constructor change, now that I fixed all the tests not to care. What do people think?
>>
>> + compute_optional_offset(_component_mirror_offset,
>> + klass_oop, vmSymbols::componentType_name(),
>> + vmSymbols::class_signature());
>>
>> Is there a followup cleanup to make it non-optional? Or, are you waiting for JPRT to be able to push hotspot and jdk changes together?
>
> Yes, please look at the _full webrev. That has the non-optional changes in it and the follow on changes to remove getComponentType as an intrinsic in C2 (will file new RFE). I really would like a compiler person to comment on it.
Sorry, I missed that. Yes, the compiler changes look good.
>
> Thanks so much,
> Coleen
>
>>
>> On Jun 30, 2014, at 5:42 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>>
>>> On 6/30/14, 1:55 AM, David Holmes wrote:
>>>> Hi Coleen,
>>>>
>>>> Your webrev links are to internal locations.
>>>
>>> Sorry, I cut/pasted the wrong links. They are:
>>>
>>> http://cr.openjdk.java.net/~coleenp/8047737_jdk/
>>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>>
>>> and the full version
>>>
>>> http://cr.openjdk.java.net/~coleenp/8047737_hotspot/
>>>
>>> Thank you for pointing this out David.
>>>
>>> Coleen
>>>
>>>>
>>>> David
>>>>
>>>> On 28/06/2014 5:24 AM, Coleen Phillimore wrote:
>>>>> Summary: Add field in java.lang.Class for componentType to simplify oop
>>>>> processing and intrinsics in JVM
>>>>>
>>>>> This is part of ongoing work to clean up oop pointers in the metadata
>>>>> and simplify the interface between the JDK j.l.C and the JVM. There's a
>>>>> performance benefit at the end of all of this if we can remove all oop
>>>>> pointers from metadata. mirror in Klass is the only one left after
>>>>> this full change.
>>>>>
>>>>> See bug https://bugs.openjdk.java.net/browse/JDK-8047737
>>>>>
>>>>> There are a couple steps to this change because Hotspot testing is done
>>>>> with promoted JDKs. The first step is this webrev:
>>>>>
>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/
>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/
>>>>>
>>>>> When the JDK is promoted, the code to remove
>>>>> ArrayKlass::_component_mirror will be changed under a new bug id.
>>>>>
>>>>> http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full
>>>>>
>>>>> Finally, a compatibility request and licensee notification will occur to
>>>>> remove the function JVM_GetComponentType.
>>>>>
>>>>> Performance testing was done that shows no difference in performance.
>>>>> The isArray() call is a compiler intrinsic which is now called instead
>>>>> of getComponentType, which was recognized as a compiler intrinsic.
>>>>>
>>>>> JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8
>>>>> tests were performed on both the change requested (1st one) and the full
>>>>> change.
>>>>>
>>>>> hotspot NSK tests were run on the hotspot-only change with a promoted JDK.
>>>>>
>>>>> Please send your comments.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>
>>
>
From mikael.vidstedt at oracle.com Mon Jun 30 23:42:08 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 30 Jun 2014 16:42:08 -0700
Subject: [8u40] RFR(S): Set T family feature bit on Niagara systems
Message-ID: <53B1F5D0.1040608@oracle.com>
Please review this 8u40 backport request. The fix was pushed to jdk9 a
couple of weeks ago and has not shown any problems.
The change from jdk9 applies to jdk8u/hs-dev without conflicts.
Bug: https://bugs.openjdk.java.net/browse/JDK-8046769
Webrev:
http://cr.openjdk.java.net/~mikael/webrevs/8046769/webrev.00/webrev/
jdk9 change:
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2399ebcea84d
Thanks,
Mikael