Re: RFR(XXS): 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64

[Bradford Wetmore]

Most of us have been at JavaOne this week.

Looks ok to me.

Brad



On 10/27/2015 11:02 AM, Volker Simonis wrote:

Resend to core-libs-dev to attract a broader audience :)

On Mon, Oct 26, 2015 at 3:32 PM, Volker Simonis
 wrote:

Hi,

can somebody please review the following trivial fix to enable the
pkcs11 tests for linux/ppc64:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8140514/
https://bugs.openjdk.java.net/browse/JDK-8140514

The pkcs11 tests need to load the native library libnss3.so the
location of which is system dependent. Until now, the test didn't
consider Linux/ppc64 systems.

The fix is simple: just add a corresponding map entry which maps the
platform to the correct library path. All the systems I've checked
(various Fedora, OpenSUSE, SLES and RHEL distros) have libnss3.so
under /usr/lib64.

Thank you and best regards,
Volker

Re: RFR (JAXP) : 8081248: Implement JEP 268: XML Catalog API

[Lance Andersen]

Hi Joe,

The current spediff, webrev seems OK to me.  Thank you for your diligence on 
this

Best
Lance
On Oct 15, 2015, at 3:52 AM, huizhe wang  wrote:

> Hi all,
> 
> Please help review JEP 268 implementation:
> https://bugs.openjdk.java.net/browse/JDK-8081248
> 
> Catalog specification:
> https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html
> 
> webrevs:
> http://cr.openjdk.java.net/~joehw/jdk9/8081248/webrev/
> 
> 
> A Catalog is basically an ordered list of entries that map external 
> references to local resources using string identifiers called 
> systemId/publicId. The main function of the Catalog API therefore is 1) parse 
> a catalog; 2) use it to find a matching entry and resolve the resource 
> referenced in an XML document.
> 
> For common use cases, an application would simply acquire a CatalogResolver 
> and set it on a parser to be used for resource resolution, refer to the test 
> for an example.
> 
> The unit test contains test cases for the simple entries. Since SQE test 
> development has been in parallel with the dev work, this unit test didn't 
> have to cover all of the functions. What it does is to test and demonstrate 
> the use in a real environment, using a CatalogResolver to actually resolves 
> resources in XML documents, while the SQE tests focus on having a full 
> coverage by matching literal strings without involving XML documents.  The 
> SQE test suite has gone through internal reviews and will start public review 
> following this review.
> 
> Thanks,
> Joe
> 
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR [9] 8140606: Update library code to use internal Unsafe

[Martin Buchholz]

Here's the plan:
- There will be an upcoming "round two" of jsr166 integration, focusing on
jtreg tests.
- We already need to massage jsr166 sources for integration, and adjusting
sun.misc.Unsafe to the new blessed name is relatively trivial.
- (There will be confusion and resistance to locking down Unsafe.  I
wouldn't be surprised if future users built their own jdk just to expose
Unsafe functionality.)

On Thu, Oct 29, 2015 at 7:12 AM, Chris Hegarty 
wrote:

>
> On 28 Oct 2015, at 21:42, Martin Buchholz  wrote:
>
> > This will cause jsr166 CVS code to no longer be able to run on jdk8, as
> it does today.  We will probably need to fork soon anyways due to Paul's
> VarHandle code, but we had not expected it to be necessary before then.  Is
> there any easy way for jsr166 CVS src/main to remain "portable" for a while
> longer?  Alternatively, what can we do to continue using "good old
> sun.misc.Unsafe" in jsr166 CVS?
>
> Right, for now I think you can continue to use sun.misc.Unsafe,
> until VarHandles arrive. Since the major 166 sync is done, the
> amount of change in this area should be small. I can help out
> with incoming changes also, until you fork.
>
> -Chris.
>
> > On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty <
> chris.hega...@oracle.com> wrote:
> > Following on from 8139891 "Prepare Unsafe for true encapsulation” [1],
> > the JDK library code should use the internal Unsafe class, and not
> > sun.misc.Unsafe.
> >
> > http://cr.openjdk.java.net/~chegar/8140606/00/
> >
> > This will be pushed to jdk9/dev once 8139891 makes its way from
> > hs-rt.
> >
> > -Chris.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8139891
> >
>
>

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

[Michael Haupt]

Hi Vladimir, Peter,

once more, thanks for all your comments. The revised webrev is at 
http://cr.openjdk.java.net/~mhaupt/8131129/webrev.01/.

Best,

Michael

> Am 28.10.2015 um 17:37 schrieb Vladimir Ivanov :
> 
> Peter,
> 
>> Hi Vladimir, I think you are right. The proposed fix alone even
>> increases the chance of duplicate class definition attempts as it delays
>> registration in cache to after whole clinit successfully finishes. I
>> would still keep this initialization rearrangement as it fixes the
>> possible publication race too. If the source of 1st exception is from
>> clinit method execution, then it would be best to skip forced class
>> initialization and delay it to its 1st use. Eager initialization does
>> not serve any purpose if the registration into cache is performed out of
>> clinit method as proposed in the fix.
>> 
>> To summarise: the proposed initialization fix would have to be
>> accompanied with removal of forced class initialization to achieve the
>> effect of your option (1) below.
> There's no benefit from skipping eager initialization - if class 
> initialization fails, the class becomes unusable anyway.
> 
> The idea was to split class init and SPECIES_DATA field init. It would allow 
> to retry Species_* class init later once the initial attempt failed. But 
> there's not much value is that right now, since VM doesn't unload generated 
> adapters. So, once code cache is exhausted there's not much JVM can do about 
> it.
> 
> Also, publishing not fully initialized Species_* class requires all users to 
> check whether the initialization is completed, which can be too much from 
> performance perspective.
> 
> So, I'm in favor of modified (3) Michael proposed.
> 
> Best regards,
> Vladimir Ivanov
> 
>> Regards, Peter
>> 
>> Michael, Peter,
>> 
>> Thanks for detailed analysis! It was a hard one to track down :-)
>> 
>> Unfortunately, I don't see how the proposed change fixes the problem.
>> 
>> The failure occurs during SpeciesData instantiation
>> (BMH$SpeciesData.). It means updateCache has not yet been called
>> from getForClass:
>> 
>> static SpeciesData getForClass(String types, Class> BoundMethodHandle> clazz) {
>> return updateCache(types, new SpeciesData(types, clazz));
>> }
>> 
>> With your changes, updateCache is called only after successful loading
>> of a class. So, the cache isn't updated if there was an error during
>> previous attempt.
>> 
>> The real problem is more severe IMO. The loaded class is useless when
>> its initialization finishes abruptly, so there's no way to instantiate
>> it or reload. Right now it is manifested as a duplicate class definition
>> attempt, but if you avoid repeated class loading it will just fail
>> slightly later - the system is already broken and there's no way to recover.
>> 
>> I see the following ways to proceed:
>>   (1) delay class initialization (fill in Species_*.SPECIES_DATA field
>> afterwards) and attempt to finish initialization on subsequent requests,
>> but skipping class loading step;
>> 
>>   (2) use VM anonymous classes (see JDK-8078602 [1]) and just retry
>> Species creation;
>> 
>>   (3) give up on that particular Species shape and throw an error
>> whenever it is requested (how it works right now, but with more
>> meaningful error message).
>> 
>> I remember I experimented with (2), but even after JDK-8078629 [2] there
>> was still measurable peak performance regression on Octane/Nashorn.
>> 
>> (1) looks more favorable and robust, but right now there shouldn't be
>> much difference - there's no support in VM to unload MH.linkTo*
>> adapters, so the failure will repeatedly occur once the code cache is full.
>> 
>> My conclusion is that it is mostly a test problem, but java.lang.invoke
>> framework should clearly communicate the reason why it fails. Since the
>> test is aware about code cache overflow problems, it looks preferable to
>> go with (1) or (3) for now. VM should throw VirtualMachineError on
>> repeated attempts to instantiate SPECIES_DATA and the test already
>> filters them out.
>> 
>> Best regards,
>> Vladimir Ivanov
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8078602
>> [2] https://bugs.openjdk.java.net/browse/JDK-8078629
>> 
>> On 10/28/15 12:19 PM, Michael Haupt wrote:
>> 
>>Dear all,
>> 
>>please review this change.
>>Bug: https://bugs.openjdk.java.net/browse/JDK-8131129
>>Webrev: http://cr.openjdk.java.net/~mhaupt/8131129/webrev.00/
>> 
>>Thanks to Peter Levart, who has contributed the actual code to fix
>>the issue.
>> 
>>The background of this is as follows. Bug 8131129 is an intermittent
>>failure in a multi-threaded test for LambdaForm caching. The failure
>>was not reproducible but used to occur on various platforms every
>>now and then. I was able to dig up some stack traces that reveal the
>>real cause in internal test logs. These traces finally confirmed a
>>suspicion that both Peter and I had had but could, for lack of
>>c

Re: RFR [9] 8140606: Update library code to use internal Unsafe

[Alan Bateman]

On 29/10/2015 14:12, Chris Hegarty wrote:

:
Yes, good point. I updated just the corba webrev.

   http://cr.openjdk.java.net/~chegar/8140606/01/corba/

I’ll be tackling ManageLocalsThread separately in the near
future so have done just the minimum in corba for now.


This looks good to me.

-Alan.

Re: RFR [9] 8140606: Update library code to use internal Unsafe

[Chris Hegarty]

On 28 Oct 2015, at 21:42, Martin Buchholz  wrote:

> This will cause jsr166 CVS code to no longer be able to run on jdk8, as it 
> does today.  We will probably need to fork soon anyways due to Paul's 
> VarHandle code, but we had not expected it to be necessary before then.  Is 
> there any easy way for jsr166 CVS src/main to remain "portable" for a while 
> longer?  Alternatively, what can we do to continue using "good old 
> sun.misc.Unsafe" in jsr166 CVS?

Right, for now I think you can continue to use sun.misc.Unsafe,
until VarHandles arrive. Since the major 166 sync is done, the 
amount of change in this area should be small. I can help out
with incoming changes also, until you fork.

-Chris.

> On Wed, Oct 28, 2015 at 12:55 PM, Chris Hegarty  
> wrote:
> Following on from 8139891 "Prepare Unsafe for true encapsulation” [1],
> the JDK library code should use the internal Unsafe class, and not
> sun.misc.Unsafe.
> 
> http://cr.openjdk.java.net/~chegar/8140606/00/
> 
> This will be pushed to jdk9/dev once 8139891 makes its way from
> hs-rt.
> 
> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8139891
> 

Re: CharSequence.subSequence optimizations

[Aleksey Shipilev]

On 10/29/2015 01:36 PM, Pavel Rappo wrote:
>> On 29 Oct 2015, at 00:48, Aleksey Shipilev  
>> wrote:
>> Doesn't that break when CharSequence implementation is mutable?
>> E.g. with StringBuilder, you cannot return "this" when "end ==
>> StringBuilder.length()" at the time of .subSequence() call.
> 
> True. This trick cannot be used in cases where CharSequence is able to change
> its length. (As far as I understand, possible changes in contents are ok.)

While Javadoc appears silent on this front, the expectation seems to be
that .subSequence returns the "detached" subsequence. See spec change here:
 https://bugs.openjdk.java.net/browse/JDK-8028757

So, I think this trick works only for the completely immutable
CharSequences, which apparently includes only Strings. And, AFAIU from
the code, String already returns "this" in cases like these?

Thanks,
-Aleksey

P.S. I think it would be evil to turn subSequence into the forwarding
view. These were considered before:
  http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027838.html

Re: [RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests

[Staffan Larsen]

Looks good (still)!

Thanks,
/Staffan
> On 28 okt. 2015, at 06:42, Chris Plummer  wrote:
> 
> Hello,
> 
> I've fixed the new jvmci tests. New webrevs found here:
> 
> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/webrev.hotspot
> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/webrev.jdk
> 
> Only the hotspot/test/compiler/jvmci files have changed since the previous 
> webrev. If you just want to look at a patch of those changes, they can be 
> found here:
> 
> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.01/jvmci.patch
> 
> The changes were straight forward. In all cases for the jvmci tests the diff 
> is:
> 
> - * @library / /testlibrary /../../test/lib
> + * @library / /testlibrary /test/lib
> 
> thanks,
> 
> Chris
> 
> On 10/26/15 3:19 PM, Ioi Lam wrote:
>> Hi Chris,
>> 
>> Your changes look good to me. I think it's better to fix the jvmci tests as 
>> well in a single push.
>> 
>> Thanks
>> - Ioi
>> 
>> On 10/26/15 2:13 PM, Chris Plummer wrote:
>>> I just pulled the latest hs-rt, and got about 30 new jvmci tests that are 
>>> using "/../../test/lib". I can fix them with this push, or file a separate 
>>> bug or send out a fix after I do this push. If I fix with this push, do you 
>>> want another review? I'll test with jprt and run the jvmci tests locally.
>>> 
>>> thanks,
>>> 
>>> Chris
>>> 
>>> 
>>> On 10/23/15 7:50 AM, Staffan Larsen wrote:
 Looks good! Thanks for doing this.
 
 /Staffan
 
> On 23 okt. 2015, at 07:54, Chris Plummer  wrote:
> 
> Hello,
> 
> Please review the following fix for 8140189:
> 
> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot
> http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk
> 
> https://bugs.openjdk.java.net/browse/JDK-8140189
> 
> Please also see the following CR, which has much more extensive 
> discussion of the problem:
> 
> jtreg produces class files outside the JTwork directory
> https://bugs.openjdk.java.net/browse/CODETOOLS-7901527
> 
> All the diffs for the tests simply replace "/../../test/lib" with 
> "/test/lib". The changes in TEST.ROOT are what allow this. It is probably 
> much easier to look at the patch than to look at each file in the webrev. 
> All the test diffs look pretty much like the following:
> 
> - * @library /testlibrary /../../test/lib
> + * @library /testlibrary /test/lib
> 
> or
> 
> - * @library /../../test/lib/share/classes
> + * @library /test/lib/share/classes
> 
> Tested with jprt. Also ran the following jtreg tests on a linux/x64 host 
> with a fastdebug build:
> 
> -Ran all hotspot jtreg tests.
> -Ran all modified jdk jtreg tests.
> -Ran jdk tier1 and tier2 jtreg tests.
> 
> There were some failures and errors, but they were replicated when 
> testing with a clean repo also and are unrelated to my changes.
> 
> thanks,
> 
> Chris
> 
>>> 
>> 
> 

Re: RFR [9] 8140606: Update library code to use internal Unsafe

[Chris Hegarty]

On 28 Oct 2015, at 22:14, Alan Bateman  wrote:

> On 28/10/2015 19:55, Chris Hegarty wrote:
>> Following on from 8139891 "Prepare Unsafe for true encapsulation” [1],
>> the JDK library code should use the internal Unsafe class, and not
>> sun.misc.Unsafe.
>> 
>> http://cr.openjdk.java.net/~chegar/8140606/00/
>> 
>> This will be pushed to jdk9/dev once 8139891 makes its way from
>> hs-rt.
> With the interim CORBA removed then can the corba repo copy of 
> ManagedLocalsThread go away instead of switching it to the internal Unsafe? 
> Otherwise looks good to me.

Yes, good point. I updated just the corba webrev.

  http://cr.openjdk.java.net/~chegar/8140606/01/corba/

I’ll be tackling ManageLocalsThread separately in the near
future so have done just the minimum in corba for now.

-Chris.

Re: CharSequence.subSequence optimizations

[Pavel Rappo]

> On 29 Oct 2015, at 00:48, Aleksey Shipilev  
> wrote:
> 
> Doesn't that break when CharSequence implementation is mutable?
> E.g. with StringBuilder, you cannot return "this" when "end ==
> StringBuilder.length()" at the time of .subSequence() call.

True. This trick cannot be used in cases where CharSequence is able to change
its length. (As far as I understand, possible changes in contents are ok.)

Thanks.

RFR(XS): 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev

[Michael Haupt]

Dear all,

cross-posted to jdk8u-dev and core-libs-dev.

Please review this change.
Issue: https://bugs.openjdk.java.net/browse/JDK-8139863
Webrev: http://cr.openjdk.java.net/~mhaupt/8139863/webrev.00

This adds a missing test to 8u-dev that was not pushed along with the feature 
backport it belongs to. The backport was approved; see 
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004185.html.

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
  Oracle is committed to developing 
practices and products that help protect the environment

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

[Gil Tene]

[Sorry for the 4 day delay in response. JavaOne sort of got in the way]

I think we are looking at two separate and almost opposite motivations, each of 
which is potentially independently valid. Each can be characterized by 
answering the question: "How does adding this to an empty while(!ready) {} spin 
loop change things?".

Putting name selection aside, one motivation can be characterized with "if I 
add this to a spinning loop, keep spinning hard and don't relinquish resources 
any more than the empty loop would, but try to leave the spin as fast as 
possible. And it would be nice if power was conserved as a side effect.". The 
other motivation can be characterized with "If I add this to a spin loop, I am 
indicating that I can't make useful progress unless stuff happens or some 
internal time limit is reached, and that it is ok to try and make better use of 
resources (including my CPU), relinquishing them more aggressively than the 
empty loop would. And it would be nice if reaction time was faster most of the 
time too". 

The two motivations are diametrically opposed in their expected effect when 
compared to the behavior of an empty spin loop that does not contain them. Both 
can be validly implemented as a nop, but they "hint" in opposite directions. 
The former is what I have been calling a spin loop hint (in the "keep spinning 
and don't let go" sense), and the latter is a "spin/yield" (in the "ok to let 
go" sense). They have different uses.

> On Oct 24, 2015, at 11:09 AM, Doug Lea  wrote:
> 
> 
> Here's one more attempt to explain why it would be a good idea
> to place, name, and specify this method in a way that is more
> general than "call this method only if you want a PAUSE instruction
> on a dedicated multicore x86":

I agree with the goal of not aiming at a processor specific behavior, and 
focusing on documenting intent and expectation. But I think that the intent 
suggested in the spinLoopHint() JavaDoc does that. As noted later in this 
e-mail, there are other things that the JVM can choose to do to work in the 
hint's intended direction.

> 
> On 10/15/2015 01:23 PM, Gil Tene wrote:
> ...
>> 
>> As noted in my proposed JavaDoc, I see the primary indication of the hint to
>> be that the reaction time to events that would cause the loop to exit (e.g.
>> in nanosecond units) is more important to the caller than the speed at which
>> the loop is executing (e.g. in "number of loop iterations per second" units).
> 
> Sure. This can also be stated:
> 
> class Thread { ...
> /**
>  * A hint to the platform that the current thread is momentarily
>  * unable to progress until the occurrence of one or more actions of
>  * one or more other threads (or that its containing loop is
>  * otherwise terminated).  The method is mainly applicable in
>  * spin-then-block constructions entailing a bounded number of
>  * re-checks of a condition, separated by spinYield(), followed if
>  * necessary with use of a blocking synchronization mechanism.  A
>  * spin-loop that invokes this method on each iteration is likely to
>  * be more responsive than it would otherwise be.
>  */
>  public static void spinYield();
> }

I like the "more responsive than it would otherwise be" part. That certainly 
describes how this is different than an empty loop. But the choice of "mainly 
applicable" in spinYield() is exactly opposite from the main use case 
spinLoopHint() is intended for (which is somewhere between "indefinite 
spinning" and "I don't care what kind of spinning"). This JavaDoc looks like a 
good description of spinYield() and it's intended main use cases, but this 
stated intent and expectations (when compared to just doing an empty spin loop) 
works in the opposite direction of what spinLoopHint's intent and expectations 
need to be for it's common use cases.

> 
>> Anyone running indefinite spin loops on a uniprocessor deserves whatever they
>> get. Yielding in order to help them out is not mercy. Let Darwin take care of
>> them instead.
>> 
>> But indefinite user-mode spinning on many-core systems is a valid and common
>> use case (see the disruptor link in my previous e-mail).
> 
>> In such situations the spinning loop should just be calling yield(), or
>> looping for a very short count (like your magic 64) and then yielding. A
>> "magically choose for me whether reaction time or throughput or being nice to
>> others is more important" call is not a useful hint IMO.
>> 
>> Like in my uniprocessor comment above, any program spinning indefinitely (or
>> for a non-trivial amount of time) with load > # cpus deserves what it gets.
> 
> The main problem here is that there are no APIs reporting whether
> load > # cpus, and no good prospects for them either, especially
> considering the use of hypervisors (that may intentionally mis-report)
> and tightly packed cloud nodes where the number of cpus currently
> available to a program may depend on random transient effects of
> co-placement with other services