Re: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame

[David Holmes]

On 6/09/2016 5:51 PM, David Simms wrote:


Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev3/


No further comments from me, but note my original comment re the 
platform specific code.


More below.


On 06/09/16 01:20, David Holmes wrote:

Hi David,

On 5/09/2016 6:02 PM, David Simms wrote:

Hi David,

I can make the checks silent, but the launcher itself produces warnings
from checked JNI (it's use of unchecked Java method invocations), and
this causes the test
(http://cr.openjdk.java.net/~dsimms/8164086/webrev2/hotspot/test/runtime/jni/checked/TestCheckedJniExceptionCheck.java.html)

to fail, with unchecked exception warnings popping up in the output.


I've looked back at your original changes in this area but I'm still
not seeing exactly where the unchecked back-to-back JNI calls are
happening. For example NewPlatformString can return with an exception
pending, but will return NULL, and the calling code has checks for NULL.



LoadMainClass:

http://hg.openjdk.java.net/jdk9/hs/jdk/file/090cbd92c744/src/java.base/share/native/libjli/java.c#l1530


Calls "CallStaticObjectMethod" from "NewPlatformString", then on line
1531 make another call "CallStaticObjectMethod".

No exception check is made. The Xcheck:jni code cannot interpreter the
return value from JNI "CallMethod" functions, so it triggers the
"unchecked" exception warning at line 1531.


Ah I see. No bug in the launcher code though as it only makes the second 
JNI call if the original did not return NULL and hence there can be no 
exception pending.


This is a limitation of the unchecked warning facility as it can't take 
control flow into account. :(






But yeah, I could adjust the test the ignore any start-up warnings and
drop the changes to the launcher...


Unless we can more clearly identify exactly where the launcher has a
problem I would prefer not to involve it in these changes. But I would
like to understand exactly why the launcher is triggering the check.



Dropped launcher changes, adjusted the test to ignore any previous
warnings.


Yep - that seems best: only monitor the test itself not the overall VM 
operation.


Thanks,
David H.
---


Cheers
/David Simms

Re: RFR: JDK-8161230 ClassLoader: add resource methods returning java.util.stream.Stream

[Mandy Chung]

> On Sep 3, 2016, at 12:55 PM, Patrick Reinhart  wrote:
> 
> Hi Mandy,
> 
> The current changes can be found here:
> 
> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.02
> 
> 
> On 02.09.2016 23:11, Mandy Chung wrote:
>>> On Sep 2, 2016, at 2:50 AM, Patrick Reinhart 
>>>  wrote:
>>> 
>>> Updated the existing 
>>> http://cr.openjdk.java.net/~reinhapa/reviews/8161230/webrev.01
>> ClassLoader::resources returning Stream is a good addition. 
>>  
>> 1386  * {@code IOException} occur getting the next resource element, it 
>> must be 
>> 1387  * wrapped into an {@code UncheckedIOException}.
>> 
>> This has been mentioned in the paragraph above. This can be dropped from 
>> @apiNote. And add:
>> 
>> @throws UncheckedIOException if I/O errors occur
>> 
> There was already an discussion about this with Alan Bateman:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042792.html
> 

I sample a few existing APIs and they document UncheckedIOException in the 
method description rather than @throws as Alan described.

> So I do not know is the best solution for this…

Your method description already covers it.  It’s fine.  line 1386-1387 in 
@apiNote is redundant that I still think can be taken out.

>> 
>> I have reservation in adding ClassLoader::systemResources static method.
>> 
>> ClassLoader::getSystemResources is a convenient method that is equivalent to 
>> calling ClassLoader::getSystemClassLoader().getResources(), since the system 
>> class loader is never null.  This method includes the resources in the 
>> application’s classpath.
>> 
>> With the new ClassLoader::getPlatformClassLoader() method, a better way to 
>> get the “system” resources from JDK (not the ones from the classpath), it 
>> can call:
>>ClassLoader::getPlatformClassLoader().resources();
>> 
>> To get a Stream of URL of the resources visible to system class loader, it 
>> can call the new resources method:
>>ClassLoader::getSystemClassLoader().resources();
>> 
>> So it doesn’t seem that the proposed systemResources static method is 
>> necessary.
>> 
> 
> Hmm... We may have overlooked this, when we started by just looking into the 
> API changes in general. I did those with Paul Sandoz in more deep in the 
> following thread: 
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042752.html
> 

> and this proposal is based on the "go" from Paul here:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/043012.html
> 

I file a bug to update the spec ClassLoader::getSystemClassLoader to return 
non-null:
   https://bugs.openjdk.java.net/browse/JDK-8165563

>> I suggest to combine the two tests in a single test, ResourcesStreamTest and 
>> add @bug JBS-id
>> 
>> ResourcesSuccessCase
>> 
>>   46 List resources = stream.collect(Collectors.toList());
>>   52 URL url = resources.get(0);
>> 
>> You can check the size first.  This can be simplified to use 
>> filter/findFirst to file the expected URL (yes need to call cl.resources 
>> again that is not an issue).
>> 
> 
> I have done this also in the new revision

testFailure method can be simplified to
long count = cl.resources(“the name”).count();
if (count != 1)
throw new Exception("expected resource is null or empty");

cl.resources("the name”)
  .filter(url -> "file:/somefile".equals(url.toExternalForm())
  .findFirst()
  .orElseThrow(…)

Mandy

Re: RFR 8164691 Stream specification clarifications for iterate and collect

[Paul Sandoz]

> On 3 Sep 2016, at 15:06, Stefan Zobel  wrote:
> 
> Hi Paul,
> 
> there's a small copy & paste error in the code samples in
> Double/Int/LongStream#iterate()
> 
> Example DoubleStream#iterate:
> 
> * {@code
> * for (T index=seed; hasNext.test(index); index = next.apply(index)) {
> * ...
> * }
> * }
> 
> That should be
> 
> * for (double index=seed; hasNext.test(index); index =
> next.applyAsDouble(index)) {
> 
> 
> Same for Int/LongStream#iterate()
> 

Thanks, well spotted, fixed in place.

When can we have generics over primitives? :-)

Paul.

Re: JEP 254: Compact Strings - length limits

[John Rose]

On Sep 6, 2016, at 2:18 PM, Tim Ellison  wrote:
> 
> People stash all sorts of things in (immutable) Strings. Reducing the
> limits in JDK9 seems like a regression.  Was there any consideration to
> using the older Java 8 StringCoding APIs for UTF-16 strings (already
> highly perf tuned) and adding additional methods for compact strings
> rather than rewriting everything as byte[]'s?

It doesn't help now, but https://bugs.openjdk.java.net/browse/JDK-8161256
proposes a better way to stash immutable bits, CONSTANT_Data.
(Caveat:  Language bindings not yet included.)  Eventually we'll get there.

— John

Re: JEP 254: Compact Strings - length limits

[Xueming Shen]

On 9/6/16, 2:18 PM, Tim Ellison wrote:



Do we have a real use case that impacted by this change?

People stash all sorts of things in (immutable) Strings. Reducing the
limits in JDK9 seems like a regression.  Was there any consideration to
using the older Java 8 StringCoding APIs for UTF-16 strings (already
highly perf tuned) and adding additional methods for compact strings
rather than rewriting everything as byte[]'s?




Hi Tim,

I'm sorry I don't get the idea of "using StringCoding APIs for UTF-16 
strings",
can you explain a little more in detail? We did try various approaches, 
byte[] +
flag, byte[] + coder, coder, char[] + coder, etc) the current one 
appears to be

the best so far based on our measurement.

Regards,
Sherman

Re: JEP 254: Compact Strings - length limits

[Tim Ellison]

On 06/09/16 19:04, Xueming Shen wrote:
> On 9/6/16, 10:09 AM, Tim Ellison wrote:
>> Has it been noted that while JEP 254 reduces the space occupied by one
>> byte per character strings, moving from a char[] to byte[]
>> representation universally means that the maximum length of a UTF-16
>> (two bytes per char) string is now halved?

Hey Sherman,

> Yes, it's a known "limit" given the nature of the approach. It is
> not considered to be an "incompatible change", because the max length
> the String class and the corresponding buffer/builder classes can
> support is really an implementation details, not a spec requirement.

Don't confuse spec compliance with compatibility.  Of course, the JEP
should not break the formal specified behavior of String etc, but the
goal was to ensure that the implementation be compatible with prior
behavior. As you know, there are many places where compatible behavior
beyond the spec is important to maintain.

> The conclusion from the discussion back then was this is something we
> can trade off for the benefits we gain from the approach. 

Out of curiosity, where was that?  I did search for previous discussion
of this topic but didn't see it -- it may be just my poor search foo.

> Do we have a real use case that impacted by this change?

People stash all sorts of things in (immutable) Strings. Reducing the
limits in JDK9 seems like a regression.  Was there any consideration to
using the older Java 8 StringCoding APIs for UTF-16 strings (already
highly perf tuned) and adding additional methods for compact strings
rather than rewriting everything as byte[]'s?

Regards,
Tim

>> Since the goal is "preserving full compatibility", this has been missed
>> by failing to allow for UTF-16 strings of length greater than
>> Integer.MAX_VALUE / 2.
>>
>> Regards,
>> Tim
>>
>>
> 

Re: JEP 254: Compact Strings - length limits

[Xueming Shen]

On 9/6/16, 12:58 PM, Charles Oliver Nutter wrote:
On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen > wrote:


Yes, it's a known "limit" given the nature of the approach. It is
not considered
to be an "incompatible change",  because the max length the String
class and
the corresponding buffer/builder classes can support is really an
implementation
details, not a spec requirement. The conclusion from the
discussion back then
was this is  something we can trade off for the benefits we gain
from the approach.
Do we have a real use case that impacted by this change?

Well, doesn't this mean that any code out there consuming String data 
that's longer than Integer.MAX_VALUE / 2 will suddenly start failing 
on OpenJDK 9?


Yes, true. But arguably the code that uses huge length of String should have
fallback code to handle the potential OOM exception, when the vm can't 
handle
the size, as there is really no guarantee the vm can handle the > 
max_value/2

length of String.


Not that such a case is a particularly good pattern, but I'm sure 
there's code out there doing it. On JRuby we routinely get bug reports 
complaining that we can't support strings larger than 2GB (and we have 
used byte[] for strings since 2006).



That was a trade-off decision to make.

Does JRuby have any better solution for such complain?  ever consider to 
go back to use char[]
to "fix" the problem? or some workaround such as to add another byte[] 
for example.


btw, the single byte only string should work just fine :-) or :-( 
depends on the character set

used.

Sherman

Re: JEP 254: Compact Strings - length limits

[John Rose]

On Sep 6, 2016, at 12:58 PM, Charles Oliver Nutter  wrote:
> 
> On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen 
> wrote:
> 
>> Yes, it's a known "limit" given the nature of the approach. It is not
>> considered
>> to be an "incompatible change",  because the max length the String class
>> and
>> the corresponding buffer/builder classes can support is really an
>> implementation
>> details, not a spec requirement. The conclusion from the discussion back
>> then
>> was this is  something we can trade off for the benefits we gain from the
>> approach.
>> Do we have a real use case that impacted by this change?
>> 
> 
> Well, doesn't this mean that any code out there consuming String data
> that's longer than Integer.MAX_VALUE / 2 will suddenly start failing on
> OpenJDK 9?
> 
> Not that such a case is a particularly good pattern, but I'm sure there's
> code out there doing it. On JRuby we routinely get bug reports complaining
> that we can't support strings larger than 2GB (and we have used byte[] for
> strings since 2006).
> 
> - Charlie

The most basic scale requirement for strings is that they support class-file
constants, which top out at a UTF8-length of 2**16.  Lengths beyond that,
to fill up the 'int' return value of String::length, are less well specified.

FTR, we could have chosen char[], int[], or long[] (not byte[]) as the backing
store for string data.  With long[] we could have strings above 4G-chars.

But it would have come with a perf. tax, since the T[].length field would need
to be combined with an extra bit or two (from a flag byte) to complete the 
length.
That's 2-3 extra instructions for loading a string length, or else a redundant
length field.  So it's a trade-off.

Likewise, choosing a third format deepens branch depth in order to get to 
payload.

Likewise, making the second format (of two) have a length field embedded in the
payload section requires a conditional load or branch, in order to load the 
string
length.  Again, more instructions.

The team has looked at 20 possibilities like these.  The current design is 
fastest.
I hope it flies.

— John

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

[Alan Burlison]

On 06/09/2016 21:01, Phil Race wrote:


FWIW "+1" from me since I just used/needed that patch to get my build to
continue on Solaris 11.3.


If you need it I have a jumbo patch that gets J9 to build on both S11.3 
and S12. I'm working on splitting it up into individual patches and 
getting them pushed into the J9 repo.


--
Alan Burlison
--

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

[Phil Race]

FWIW "+1" from me since I just used/needed that patch to get my build to 
continue on Solaris 11.3.


-phil.

On 9/6/2016 10:28 AM, Roger Riggs wrote:

Hi Alan,

Not a problem, I usually use mq to wrangle patches. (per repo)

Thanks, Roger


On 9/6/2016 1:25 PM, Alan Burlison wrote:

On 06/09/2016 18:10, Roger Riggs wrote:


ok, I will sponsor it.


Thanks.


(Usually the patches are relative to the repo being modified).


I can regen it if you want, I've been doing a lot of cross-repo 
patches and have got into the habit of generating them from the 
topmost repo ;-)

Re: JEP 254: Compact Strings - length limits

[Charles Oliver Nutter]

On Tue, Sep 6, 2016 at 1:04 PM, Xueming Shen 
wrote:

> Yes, it's a known "limit" given the nature of the approach. It is not
> considered
> to be an "incompatible change",  because the max length the String class
> and
> the corresponding buffer/builder classes can support is really an
> implementation
> details, not a spec requirement. The conclusion from the discussion back
> then
> was this is  something we can trade off for the benefits we gain from the
> approach.
> Do we have a real use case that impacted by this change?
>

Well, doesn't this mean that any code out there consuming String data
that's longer than Integer.MAX_VALUE / 2 will suddenly start failing on
OpenJDK 9?

Not that such a case is a particularly good pattern, but I'm sure there's
code out there doing it. On JRuby we routinely get bug reports complaining
that we can't support strings larger than 2GB (and we have used byte[] for
strings since 2006).

- Charlie

Re: Filing Bugs Against the Core Libs

[Martin Buchholz]

On Mon, Aug 29, 2016 at 8:25 PM, Russ Harmon  wrote:

>
> > The actual code that throws it doesn't know the exact reason.
>
>
> To my understanding though, the reason is not outside of the purview of the
> JDK (aka, the rejection is not decided upon by outside code), and therefore
> some refactoring of the existing code could make it known.
>
>
Like David, I have a hard time seeing how to make this clearly better.  The
only interface to the RejectedExecutionHandler is the rejectedExecution
method, and that does not allow for any way to pass a reason.


>
> > But you
> > seem to be running a custom RejectedExeceptionHandler so it should be
> > able to determine whether the executor is shutdown, or if using a
> > bounded queue which may have become full.
> >
>
> There's a race condition if I do that.


It's true we have a "reason reporting race" then.
ThreadPoolExecutor code is doing something like

if (isShutdown()) handler.rejectedExecution(command, this)

but how to pass the reason to the handler?

In practice, rechecking the shutdown status in the handler is good enough
for most monitoring purposes.  If the pool turns out to be shutdown, but
the shutdown happened in a race, does it matter to the caller?  Retry will
be futile in such a case anyway.


> If the executor has not been
> shutdown, and the executor has reached capacity, the
> RejectedExceptionHandler will be called. I can then check the queue size in
> the RejectedExceptionHandler, but it's possible that tasks completed before
> I'm able to check the size, so the queue won't appear full.
>
> I think that this is actually what has occurred in my case. The stack trace
> I linked earlier shows a non-full queue, but I know that the executor was
> not shutting down. Therefore, it must have been caused by the queue filling
> up, then depleting before the size was read for generation of the error
> message.
>
>

Re: JEP 254: Compact Strings - length limits

[Xueming Shen]

On 9/6/16, 10:09 AM, Tim Ellison wrote:

Has it been noted that while JEP 254 reduces the space occupied by one
byte per character strings, moving from a char[] to byte[]
representation universally means that the maximum length of a UTF-16
(two bytes per char) string is now halved?

Hi Tim,

Yes, it's a known "limit" given the nature of the approach. It is not 
considered

to be an "incompatible change",  because the max length the String class and
the corresponding buffer/builder classes can support is really an 
implementation
details, not a spec requirement. The conclusion from the discussion back 
then
was this is  something we can trade off for the benefits we gain from 
the approach.

Do we have a real use case that impacted by this change?

Thanks,
Sherman


Since the goal is "preserving full compatibility", this has been missed
by failing to allow for UTF-16 strings of length greater than
Integer.MAX_VALUE / 2.

Regards,
Tim

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

[Roger Riggs]

Hi Alan,

Not a problem, I usually use mq to wrangle patches. (per repo)

Thanks, Roger


On 9/6/2016 1:25 PM, Alan Burlison wrote:

On 06/09/2016 18:10, Roger Riggs wrote:


ok, I will sponsor it.


Thanks.


(Usually the patches are relative to the repo being modified).


I can regen it if you want, I've been doing a lot of cross-repo 
patches and have got into the habit of generating them from the 
topmost repo ;-)

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

[Alan Burlison]

On 06/09/2016 18:10, Roger Riggs wrote:


ok, I will sponsor it.


Thanks.


(Usually the patches are relative to the repo being modified).


I can regen it if you want, I've been doing a lot of cross-repo patches 
and have got into the habit of generating them from the topmost repo ;-)


--
Alan Burlison
--

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

[Roger Riggs]

ok, I will sponsor it.

(Usually the patches are relative to the repo being modified).

Thanks, Roger


On 9/6/2016 3:35 AM, Alan Burlison wrote:

On 01/09/2016 14:34, Alan Burlison wrote:


Changes looks good for me.


Thanks.

Could someone possibly sponsor this for me? I don't have commit rights
yet...


Ping...

Re: Filing Bugs Against the Core Libs

[Russ Harmon]

On Mon, Aug 29, 2016 at 7:27 PM David Holmes 
wrote:

> Hi Russ,
>
> On 26/08/2016 5:39 AM, Russ Harmon wrote:
> > Hello,
> >
> > I'd like to report a (minor) feature request / bug in the core libs.
> What's
> > the best way for me to do that?
>
> Brian already gave you the general answer, but in this case one of your
> colleagues at Google, Martin Buccholz, is one of the primary maintainers
> of the java.util.concurrent code.
>

Thanks for the pointer. I'll reach out to Martin.


> > I recently ran into this stack trace
> > .
> It's
> > not very useful to me, since I can't determine from either the message or
> > the stack trace why the task was rejected. It would be much more helpful
> if
> > either a) the message stated the reason, or b) the stack trace pointed
> at a
> > line of code which unambiguously indicated a reason (e.x. a list of "if"
> > statements which throw this exception, so I can look at the condition to
> > see why the task was rejected)
>
> It is documented to be thrown:
>
> * If the task cannot be submitted for execution, either because this
> * executor has been shutdown or because its capacity has been reached,
> * the task is handled by the current {@code RejectedExecutionHandler}.
>
> The actual code that throws it doesn't know the exact reason.


To my understanding though, the reason is not outside of the purview of the
JDK (aka, the rejection is not decided upon by outside code), and therefore
some refactoring of the existing code could make it known.


> But you
> seem to be running a custom RejectedExeceptionHandler so it should be
> able to determine whether the executor is shutdown, or if using a
> bounded queue which may have become full.
>

There's a race condition if I do that. If the executor has not been
shutdown, and the executor has reached capacity, the
RejectedExceptionHandler will be called. I can then check the queue size in
the RejectedExceptionHandler, but it's possible that tasks completed before
I'm able to check the size, so the queue won't appear full.

I think that this is actually what has occurred in my case. The stack trace
I linked earlier shows a non-full queue, but I know that the executor was
not shutting down. Therefore, it must have been caused by the queue filling
up, then depleting before the size was read for generation of the error
message.


> Cheers,
> David
>
> > Thanks,
> > Russ Harmon
> > Google Site Reliability Engineer
> >
>

Re: RFR: JDK-8165161 Solaris: /usr/ccs /opt/sfw and /opt/csw are dead, references should be expunged

[Roger Riggs]

Hi Alan,

Looks ok from the core-libs perspective.

Roger


On 9/6/2016 3:38 AM, Alan Burlison wrote:

On 01/09/2016 18:43, Alan Burlison wrote:


I posted this originally on build-dev, it was suggested I should also
post it to core-libs-dev for review of some of the changes.

/usr/ccs /opt/sfw and /opt/csw are all obsolete and should be removed
from the Solaris-related build infrastructure.

Bug:https://bugs.openjdk.java.net/browse/JDK-8165161
Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165161/

JPRT hotspot tests all pass.


Ping...

Re: Participating on https://bugs.openjdk.java.net/browse/JDK-8156070

[Aleksey Shipilev]

On 09/06/2016 01:49 AM, Jonathan Bluett-Duncan wrote:
> I decided to have a crack at "JDK-8134373 explore potential uses of
> convenience factories within the JDK" today. I recognise it's only a P4 bug
> and most likely won't be prioritised for Java 9, but I believe I found a
> number of places where uses of
> "Collections.unmodifiableList(Arrays.asList(...))" and "Arrays.asList(..)"
> can be replaced with "List.of(...)". I've thus made some changes to my
> local clone of the jdk9 codebase.
> 
> I'm now at a point where I'm unfamiliar with what one does next when
> contributing to OpenJDK, so I wonder if you'd kindly advise me on what my
> next step(s) are.

See: http://openjdk.java.net/contribute/

In short, sign and send OCA, prepare and send the patch for review, work
with your sponsor.

Thanks,
-Aleksey

Re: RFR (S): JDK-8164086: Checked JNI pending exception check should be cleared when returning to Java frame

[David Simms]

Updated webrev: http://cr.openjdk.java.net/~dsimms/8164086/webrev3/



On 06/09/16 01:20, David Holmes wrote:

Hi David,

On 5/09/2016 6:02 PM, David Simms wrote:

Hi David,

I can make the checks silent, but the launcher itself produces warnings
from checked JNI (it's use of unchecked Java method invocations), and
this causes the test
(http://cr.openjdk.java.net/~dsimms/8164086/webrev2/hotspot/test/runtime/jni/checked/TestCheckedJniExceptionCheck.java.html) 


to fail, with unchecked exception warnings popping up in the output.


I've looked back at your original changes in this area but I'm still 
not seeing exactly where the unchecked back-to-back JNI calls are 
happening. For example NewPlatformString can return with an exception 
pending, but will return NULL, and the calling code has checks for NULL.




LoadMainClass:

http://hg.openjdk.java.net/jdk9/hs/jdk/file/090cbd92c744/src/java.base/share/native/libjli/java.c#l1530

Calls "CallStaticObjectMethod" from "NewPlatformString", then on line 
1531 make another call "CallStaticObjectMethod".


No exception check is made. The Xcheck:jni code cannot interpreter the 
return value from JNI "CallMethod" functions, so it triggers the 
"unchecked" exception warning at line 1531.




But yeah, I could adjust the test the ignore any start-up warnings and
drop the changes to the launcher...


Unless we can more clearly identify exactly where the launcher has a 
problem I would prefer not to involve it in these changes. But I would 
like to understand exactly why the launcher is triggering the check.




Dropped launcher changes, adjusted the test to ignore any previous warnings.

Cheers
/David Simms

Re: RFR: JDK-8165161 Solaris: /usr/ccs /opt/sfw and /opt/csw are dead, references should be expunged

[Alan Burlison]

On 01/09/2016 18:43, Alan Burlison wrote:


I posted this originally on build-dev, it was suggested I should also
post it to core-libs-dev for review of some of the changes.

/usr/ccs /opt/sfw and /opt/csw are all obsolete and should be removed
from the Solaris-related build infrastructure.

Bug:https://bugs.openjdk.java.net/browse/JDK-8165161
Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165161/

JPRT hotspot tests all pass.


Ping...

--
Alan Burlison
--

Re: RFR: JDK-8161360,,Deprecated vfork() should not be used on Solaris

[Alan Burlison]

On 01/09/2016 14:34, Alan Burlison wrote:


Changes looks good for me.


Thanks.

Could someone possibly sponsor this for me? I don't have commit rights
yet...


Ping...

--
Alan Burlison
--