Re: RFR [8038333] java/lang/ref/EarlyTimeout.java failed

[Mandy Chung]

On 3/26/2014 3:57 PM, David Holmes wrote:

Ivan,

I think the problem is that the EarlyTimeout threads can complete 
their remove(TIMEOUT) before the main thread has started them all, 
cleared the reference and called System.gc().


Depending on exactly what is being tested, the EarlyTimeout threads 
may need to wait on another latch that is signalled by the main thread 
after the gc() call returns. Still no guarantee that the gc will do 
its work before the timeout elapses.




This is similar to what I have been thinking.  I believe the 
EarlyTimeout threads don't need the startedSignal.countDown; instead it 
can have a signal latch with 1 count.  The EarlyTimeout threads awaits 
on the signal latch.  The main thread will call signal.countDown after 
System.gc() and we can add a check weakReference.isEnqueued to make sure 
before we awake the threads to proceed the queue.remove call.


Ivan - for the error message, perhaps you can simply do this:

  if (nonNullRefCount != 1) {
   throw new RuntimeException(nonNullRefCount + " references were removed 
from queue");
  }


Mandy


David

On 27/03/2014 6:18 AM, Ivan Gerasimov wrote:

Thank you Mandy!


Are you able to reproduce the test failure?


Yes, I could easily reproduce the failure when I reduced the timeout to
10 ms.
With the timeout reduced, the test fails every third time on my machine.


I think the test verifies that only one thread gets the reference is a
good test.


But if none of the threads could get the reference, it should not cause
the failure of the test.
It only means that during this particular run we could not have tested
what we needed.
We could retry, but I'm not sure it's worth complicating the test.
It's easier to ignore the failure, taking into account that it happens
rarely.


I think the race is due to the threads get to call queue.remove as
soon as both threads decrement the count of the latch that can be well
before the reference is enqueued.


The problem is that we have no way to block the main thread until there
is a reference in the queue.
I improved the situation a bit, having moved the await() after the call
of gc().


It'd be good to add additional information in the test to help
diagnosing test failure.


I added reporting to stderr about being unable to remove a reference
from the queue.
I believe we shouldn't treat it as an error, and should simply ignore 
it.


Would you please have a look at the updated webrev:
http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/

Sincerely yours,
Ivan

Re: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null

[Xueming Shen]

Stephen,

public DateTimeFormatter withResolverFields(TemporalField... resolverFields) {
- Objects.requireNonNull(resolverFields, "resolverFields");
- Set fields = new HashSet<>(Arrays.asList(resolverFields));
+ Set fields = null;
+ if (resolverFields != null) {
+ fields = Collections.unmodifiableSet(new 
HashSet<>(Arrays.asList(resolverFields)));
+ }
if (Objects.equals(this.resolverFields, fields)) {
return this;
}
- fields = Collections.unmodifiableSet(fields);
return new DateTimeFormatter(printerParser, locale, decimalStyle, 
resolverStyle, fields, chrono, zone);
} Isn't it better to do

+ if (resolverFields != null && resolverFields.length != 0) {
+ fields = Collections.unmodifiableSet(new 
HashSet<>(Arrays.asList(resolverFields)));
+ }

(similar size check for the set version) ? -Sherman



On 03/12/2014 03:45 AM, Stephen Colebourne wrote:

This is a request for review of this bug:
https://bugs.openjdk.java.net/browse/JDK-8036818

The method DateTimeFormatter withResolverFields() is supposed to
accept null. This is to allow a coy of the formatter to be returned
reset to the original state of having no resolver fields. The docs
say:
"@param resolverFields the new set of resolver fields, null if no fields"
which was written to indicate that resetting to null is permitted.

The fix is to check for null and return a copy of the formatter. Note
that there are two variations of the method which need fixing.

Proposed patch:
https://gist.github.com/jodastephen/9395197
The patch includes no spec changes.
The patch fixes the broken TCK tests.

I need a reviewer and a committer please.
thanks
Stephen

Re: RFR [8038333] java/lang/ref/EarlyTimeout.java failed

[David Holmes]

Ivan,

I think the problem is that the EarlyTimeout threads can complete their 
remove(TIMEOUT) before the main thread has started them all, cleared the 
reference and called System.gc().


Depending on exactly what is being tested, the EarlyTimeout threads may 
need to wait on another latch that is signalled by the main thread after 
the gc() call returns. Still no guarantee that the gc will do its work 
before the timeout elapses.


David

On 27/03/2014 6:18 AM, Ivan Gerasimov wrote:

Thank you Mandy!


Are you able to reproduce the test failure?


Yes, I could easily reproduce the failure when I reduced the timeout to
10 ms.
With the timeout reduced, the test fails every third time on my machine.


I think the test verifies that only one thread gets the reference is a
good test.


But if none of the threads could get the reference, it should not cause
the failure of the test.
It only means that during this particular run we could not have tested
what we needed.
We could retry, but I'm not sure it's worth complicating the test.
It's easier to ignore the failure, taking into account that it happens
rarely.


I think the race is due to the threads get to call queue.remove as
soon as both threads decrement the count of the latch that can be well
before the reference is enqueued.


The problem is that we have no way to block the main thread until there
is a reference in the queue.
I improved the situation a bit, having moved the await() after the call
of gc().


It'd be good to add additional information in the test to help
diagnosing test failure.


I added reporting to stderr about being unable to remove a reference
from the queue.
I believe we shouldn't treat it as an error, and should simply ignore it.

Would you please have a look at the updated webrev:
http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/

Sincerely yours,
Ivan

Re: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl

[Aleksej Efimov]

The link to the JBS bug is incorrect in original review request. This 
one is a correct one: https://bugs.openjdk.java.net/browse/JDK-8035437.


Sorry for the confusion,
Aleksej

On 26.03.2014 20:44, Aleksej Efimov wrote:

Lance,
The document implementation (DocumentImpl) returned by 
'builder.newDocument()' should implement org.w3c.dom.Node and 
org.w3c.dom.Document interfaces, but shouldn't have the 
'getXmlVersion' method (in Node, Document and DocumentImpl) - it's a 
main item required by Apache bug. So it means, that we need to 
substitute all three classes (Document,Node and DocumentImpl). The 
test should be executed with JDKs Node, Document, but DocumentImpl 
should be compiled against incorrect interfaces. I don't see, how I 
can implement it with jtreg keywords (the main problem is splitting 
the compilation of DocumentImpl (fake Node, Document) and the test run 
(only fake DocumentImpl).


The only reason why StringBuffer is not used here - the process of how 
updates were moved from Xerces to JAXP: revision by revision. And I 
don't think that it should prevent us from replacing it with faster 
StringBuilder =). Will change it to StringBuilder.


Thank you,
Aleksej

On 03/26/2014 09:04 PM, Lance Andersen wrote:
Any reason not to use StringBuilder in place of StringBuffer in 
XMLEntityManager.java


other than the above and my question on the need of using run.sh, it 
is OK


On Mar 26, 2014, at 12:54 PM, Lance Andersen 
mailto:lance.ander...@oracle.com>> wrote:



Hi Aleksej,

Do you really need to use run.sh?  If possible it would be better to 
try and avoid providing a script and  use the jtreg keywords.


Best
Lance
On Mar 26, 2014, at 12:39 PM, Aleksej Efimov 
mailto:aleksej.efi...@oracle.com>> wrote:



Hello,

Can I ask for a review for the update of DOMSerializerImpl class 
[1] to the latest Apache Xerces implementation.

The following changes were made:
1. The DOMSerializerImpl update: The Xerces class was used as a 
base [2]; the  476047 and 473125 revisions from Xerces was excluded 
(they will be resolved as a part of JDK-8035467 - move to Xalan 
serializer bug); the jaxp 632 revision was applied to new version 
of this class.
2. The DOMSerializerImpl.java file was reformated, because of 
not-good formatting in original file from Apache repo [2].
3. Other changes related to the DOMSerializerImpl update were 
applied from Xerces repo to JDK(the full revisions list can be 
found in the JBS [1]).
4. All license headers were updated to the latest version of Apache 
header in modified files.
5. New regression test was added to reproduce a problem described 
in Apache bug XERCESJ-1007 [3].


Webrevs for these changes:
http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp 

http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk 



Testing:
JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml 
xml_schema): pass

JTREG tests (javax/xml, jdk_other): pass

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-6339023
[2] 
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup

[3] https://issues.apache.org/jira/browse/XERCESJ-1007





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






 

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(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles

[Igor Ignatyev]

Hi Chris,


This is very nice.  Are there plans to do this for the other existing tests as 
well?
sure, but we didn't have enough time to do it in 8u20 timeframe. So I'd 
like to push these changes 1st, since we need this to cover 'Speedup 
catch exceptions'. Other tests will be rewrite later. I hope we'll have 
time in jdk 9 to refactor all tests in MethodHandles.


Thanks,
Igor

On 03/27/2014 12:38 AM, Christian Thalinger wrote:


On Mar 24, 2014, at 1:33 PM, Igor Ignatyev  wrote:


Hi all,

Please review the patch:

Problems:
- MethodHandlesTest::testCatchException() doesn't provide enough testing of 
j.l.i.MethodHandles::catchException().
- MethodHandlesTest contains more than 3k lines, an auxiliary code together w/ 
a test code, many methods aren't connected w/ each other, etc. All this leads 
to that it is very very hard to understand, maintain.


Yes, it is.



Fix:
- the auxiliary code was moved to testlibray
- the test code was moved to a separate subpackage


This is very nice.  Are there plans to do this for the other existing tests as 
well?


- random signature is used for target and handler
- added scenarios w/ different return types

webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/
jbs: https://bugs.openjdk.java.net/browse/JDK-8038186
--
Igor
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles

[Christian Thalinger]

On Mar 24, 2014, at 1:33 PM, Igor Ignatyev  wrote:

> Hi all,
> 
> Please review the patch:
> 
> Problems:
> - MethodHandlesTest::testCatchException() doesn't provide enough testing of 
> j.l.i.MethodHandles::catchException().
> - MethodHandlesTest contains more than 3k lines, an auxiliary code together 
> w/ a test code, many methods aren't connected w/ each other, etc. All this 
> leads to that it is very very hard to understand, maintain.

Yes, it is.

> 
> Fix:
> - the auxiliary code was moved to testlibray
> - the test code was moved to a separate subpackage

This is very nice.  Are there plans to do this for the other existing tests as 
well?

> - random signature is used for target and handler
> - added scenarios w/ different return types
> 
> webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8038186
> -- 
> Igor
> ___
> mlvm-dev mailing list
> mlvm-...@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: RFR [8038333] java/lang/ref/EarlyTimeout.java failed

[Ivan Gerasimov]

Thank you Mandy!


Are you able to reproduce the test failure?


Yes, I could easily reproduce the failure when I reduced the timeout to 
10 ms.

With the timeout reduced, the test fails every third time on my machine.

I think the test verifies that only one thread gets the reference is a 
good test.


But if none of the threads could get the reference, it should not cause 
the failure of the test.
It only means that during this particular run we could not have tested 
what we needed.

We could retry, but I'm not sure it's worth complicating the test.
It's easier to ignore the failure, taking into account that it happens 
rarely.


I think the race is due to the threads get to call queue.remove as 
soon as both threads decrement the count of the latch that can be well 
before the reference is enqueued.


The problem is that we have no way to block the main thread until there 
is a reference in the queue.
I improved the situation a bit, having moved the await() after the call 
of gc().


It'd be good to add additional information in the test to help 
diagnosing test failure.


I added reporting to stderr about being unable to remove a reference 
from the queue.

I believe we shouldn't treat it as an error, and should simply ignore it.

Would you please have a look at the updated webrev:
http://cr.openjdk.java.net/~igerasim/8038333/1/webrev/

Sincerely yours,
Ivan

Re: ProcessReaper: single thread reaper

[Peter Levart]

On 03/26/2014 07:09 PM, Martin Buchholz wrote:

On Wed, Mar 26, 2014 at 11:01 AM, Roger Riggswrote:


  Hi  Martin,

My solution to that is to export a public API that can be used
by other subsystems that fork processes.  Some peaceful cooperation is
required.


Roger,

I don't think cooperation is possible - your solution must be compatible.
  Other folks may have written native library code 20 years ago that starts
a subprocess and then waits for it, not even designed to coexist with a JVM.


SIGCHLD then...

In theory, if registered with sigaction(), the handler could chain the 
old handler so that a 3rd party library code written 20 years ago, 
registering it's own SIGCHLD handler, could co-exist, provided that it 
registers it's handler 1st or that it chains the old handler as well.


The handler already gets all the data we need (from Linux man page):

   * SIGCHLD fills in si_pid, si_uid, si_status, si_utime and 
si_stime, providing information about the child.  The si_pid field is 
the process ID  of  the  child;  si_uid  is  the
 child's real user ID.  The si_status field contains the exit 
status of the child (if si_code is CLD_EXITED), or the signal number 
that caused the process to change state.  The
 si_utime and si_stime contain the user and system CPU time 
used by the child process; these fields do not include the times used by 
waited-for  children  (unlike  getrusage(2)
 and  time(2)).   In  kernels  up to 2.6, and since 2.6.27, 
these fields report CPU time in units of sysconf(_SC_CLK_TCK).  In 2.6 
kernels before 2.6.27, a bug meant that these
 fields reported time in units of the (configurable) system 
jiffy (see time(7)).


This seems to be POSIX api. So it should be present on Solaris/OS X/AIX too?

Regards, Peter

Re: ProcessReaper: single thread reaper

[Roger Riggs]

Hi  Martin,

My solution to that is to export a public API that can be used
by other subsystems that fork processes.  Some peaceful cooperation is 
required.


Roger


On 3/26/14 10:54 AM, Martin Buchholz wrote:
Peter and Roger, please stop going down this road until you have a 
solution for my show-stopper problem, that in the below you are 
reaping children that don't belong to java.lang.Process


+pid = waitpid(-1, &exitValue, 0);



On Wed, Mar 26, 2014 at 10:49 AM, Peter Levart > wrote:


Hi Roger,

Your current implementation works for the demostrated use case in
UNIXProcess, where a single call-back is registered for a pid. If
you wanted to register another, the waitList and exitList might
have already removed the pid from them as a result of the 1st
call-back already been serviced before registering the 2nd one.

So you might want to keep the entry in exitList for a while, to
accommodate for 2nd and subsequent call-back registration if such
usage is to be needed.

This is what I tried to do in the following code:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ProcessWaiter/webrev.01/


I leveraged ConcurrentHashMap and CompletableFuture for the task.
As an example of usage in UNIXProcess, I modified the linux
variant only. A single waiter thread is  dispatching exit statuses
from exited children to CompletableFutures. Various waitFor() etc.
methods in UNIXProcess are implemented in terms of
Future.get()/isDone() methods and clean-up is implemented by
dispatching asynchronously a cleanup task to the thread pool, so
that multiple threads can help draining buffers. Children that are
collected by waiter thread but nobody has asked to be notified
about get expunged from the map after a time-out.

I haven't done any checking for live pids as you did in
checkLiveness() because in current usage, a pid that registers a
Future entry in the map is taken from a successful forkAndExec()
call so it will definitely be collected by the waitLoop() when the
child process exits. The only possibility that this does not
happen is if the same pid was waited for somewhere else (not in
the waitLoop()). So if this is to be supported, a scan of live
pids will be necessary from time to time and not only when
there're no unwaited children (suppose there is a long-lived child
running indefinitely).

What do you think?

Regards, Peter



On 03/25/2014 10:47 PM, Roger Riggs wrote:

Hi Martin,

Two cases, one current and one future.

In the current case, Process can spawn a process and the process
can exit before Process can register the callback to get the
exitValue.
Peter pointed out this race in his comments.
The exitValue needs to be saved (for some time yet to be determined)
to allow the Process to register and get its callback with the
exitValue.

The second case is future looking to the case where a child process
not spawned by Process is exiting.  It might be due to a child being
inherited from a dieing child or due to some different subprocess
launcher.

When the JEP 102 process work happens, it should be possible to
wait or get called back for those non-spawned processes.

The single (smaller) number of threads has been requested to handle
processes that control a large number of children. It could be from
a thread pool, either dedicated or common.  The common threadpool
does not expect its tasks to hang for an indefinite period as might
occur when waiting for along running process to exit.

Thanks, Roger


On 3/25/14 2:39 PM, Martin Buchholz wrote:

What happens if the pid you get back is a subprocess not created by 
ProcessBuilder?
+pid = waitpid(-1, &exitValue, 0);
---

What is the advantage of having a single thread?  Are you just
trying to save threads?  The cost of the reaper threads is much
lower than usual because of the small stack size.



On Tue, Mar 25, 2014 at 7:05 AM, Peter Levart
mailto:peter.lev...@gmail.com>> wrote:

On 03/24/2014 10:05 PM, roger riggs wrote:

Hi Rob, Martin, et.al .

I've prototyped (for 9) a thread reaper[1] that uses a
single thread to wait for exiting
processes and calling back to the process with the exit
status.
the interesting part is getting the exit status back to the
Process that needs it
It needs more testing and hardening.

I had not considered using a signal handler for SIGCHLD but
that's an option,
though we need to be very careful about thread usage.

Roger

p.s. comments on the single thread reaper appreciated (in a
new thread)
[1] http://cr.openjdk.java.net/~rriggs/

Re: ProcessReaper: single thread reaper

[Peter Levart]

Hi Roger,

Your current implementation works for the demostrated use case in 
UNIXProcess, where a single call-back is registered for a pid. If you 
wanted to register another, the waitList and exitList might have already 
removed the pid from them as a result of the 1st call-back already been 
serviced before registering the 2nd one.


So you might want to keep the entry in exitList for a while, to 
accommodate for 2nd and subsequent call-back registration if such usage 
is to be needed.


This is what I tried to do in the following code:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ProcessWaiter/webrev.01/

I leveraged ConcurrentHashMap and CompletableFuture for the task. As an 
example of usage in UNIXProcess, I modified the linux variant only. A 
single waiter thread is  dispatching exit statuses from exited children 
to CompletableFutures. Various waitFor() etc. methods in UNIXProcess are 
implemented in terms of Future.get()/isDone() methods and clean-up is 
implemented by dispatching asynchronously a cleanup task to the thread 
pool, so that multiple threads can help draining buffers. Children that 
are collected by waiter thread but nobody has asked to be notified about 
get expunged from the map after a time-out.


I haven't done any checking for live pids as you did in checkLiveness() 
because in current usage, a pid that registers a Future entry in the map 
is taken from a successful forkAndExec() call so it will definitely be 
collected by the waitLoop() when the child process exits. The only 
possibility that this does not happen is if the same pid was waited for 
somewhere else (not in the waitLoop()). So if this is to be supported, a 
scan of live pids will be necessary from time to time and not only when 
there're no unwaited children (suppose there is a long-lived child 
running indefinitely).


What do you think?

Regards, Peter


On 03/25/2014 10:47 PM, Roger Riggs wrote:

Hi Martin,

Two cases, one current and one future.

In the current case, Process can spawn a process and the process
can exit before Process can register the callback to get the exitValue.
Peter pointed out this race in his comments.
The exitValue needs to be saved (for some time yet to be determined)
to allow the Process to register and get its callback with the exitValue.

The second case is future looking to the case where a child process
not spawned by Process is exiting.  It might be due to a child being
inherited from a dieing child or due to some different subprocess 
launcher.


When the JEP 102 process work happens, it should be possible to
wait or get called back for those non-spawned processes.

The single (smaller) number of threads has been requested to handle
processes that control a large number of children.  It could be from
a thread pool, either dedicated or common.  The common threadpool
does not expect its tasks to hang for an indefinite period as might
occur when waiting for along running process to exit.

Thanks, Roger


On 3/25/14 2:39 PM, Martin Buchholz wrote:

What happens if the pid you get back is a subprocess not created by 
ProcessBuilder?
+pid = waitpid(-1, &exitValue, 0);
---

What is the advantage of having a single thread?  Are you just trying 
to save threads?  The cost of the reaper threads is much lower than 
usual because of the small stack size.




On Tue, Mar 25, 2014 at 7:05 AM, Peter Levart > wrote:


On 03/24/2014 10:05 PM, roger riggs wrote:

Hi Rob, Martin, et.al .

I've prototyped (for 9) a thread reaper[1] that uses a single
thread to wait for exiting
processes and calling back to the process with the exit status.
the interesting part is getting the exit status back to the
Process that needs it
It needs more testing and hardening.

I had not considered using a signal handler for SIGCHLD but
that's an option,
though we need to be very careful about thread usage.

Roger

p.s. comments on the single thread reaper appreciated (in a new
thread)
[1] http://cr.openjdk.java.net/~rriggs/webrev-waitpid/




Hi Roger,

I think I found a little race. Suppose reaper task is still alive
and that all consumers have been serviced (consumerCount is 0).
The reaper task waits for 500 millis for next consumer to be
registered, but times out. Before calling
"reaperThread.release()", new consumer comes around and registers
itself, also calling runReaper(), but since
reaperThread.release() has not yet been called by old reaper
task, new reaper task is not submitted to commonPool. The old
reaper task finishes, leaving one consumer on the waitingList
with no reaper task to service it. If no new consumers get
registered, the waiting consumer will never be notified...

The simplest solution for this race, I think, would be to have a
dedicated long-running thread. It could be spa

Re: Improve timezone mapping for AIX platform

[Volker Simonis]

Hi Jonathan,

thanks for doing this change. Please find some comments below:

1. please update the copyright year to 2014 in every file you touch

2. in CopyFiles.gmk you can simplify the change by joining the windows
and aix cases because on Windows OPENJDK_TARGET_OS is the same like
OPENJDK_TARGET_OS_API_DIR. So you can write:

ifneq ($(findstring $(OPENJDK_TARGET_OS), windows aix), )

  TZMAPPINGS_SRC := $(JDK_TOPDIR)/src/$(OPENJDK_TARGET_OS)/lib

  $(LIBDIR)/tzmappings: $(TZMAPPINGS_SRC)/tzmappings
$(call install-file)

  COPY_FILES += $(LIBDIR)/tzmappings

endif

3. regarding the changes proposed by Masayoshi: I agree that we should
put the AIX timezone mapping code in its own function, but I don't
think that getPlatformTimeZoneID() would be the right place. As far as
I understand, getPlatformTimeZoneID() is used to get a platform time
zone id if the environment variable "TZ" is not set. I don't know a
way how this could be done on AIX (@Jonathan: maybe you know?). If
there would be a way to get the time zone from some system files or
so, then we should put this code into the AIX version of
getPlatformTimeZoneID().

But the current AIX code contributed by Jonathan, actually uses the
time zone id from the "TZ" environment variable and just maps it to a
Java compatible time zone id. So I'd suggest to refactor this code
into a function like for example "static const char*
mapPlatformToJavaTimzone(const char* tz)" and call that from
findJavaTZ_md(). I think that would make the code easier to
understand.

@Masayoshi: what do you think, would you agree with such a solution.

4. I agree with Masayoshi that you should use the existing getGMTOffsetID()

5. Please notice that your change breaks all Unix builds except AIX because of:

 759 }
 760 tzerr:
 761 if (javatz == NULL) {
 762 time_t offset;
...
 782 }
 783 #endif

I think that should read:

 759
 760 tzerr:
 761 if (javatz == NULL) {
 762 time_t offset;
...
 782 }
 783 #endif
 784 }

Refactoring the code in an extra function will make that error more
evident anyway.

But please always build at least on one different platform (i.e.
Linux) to prevent such errors in the future.

Regards,
Volker


On Wed, Mar 26, 2014 at 10:27 AM, Masayoshi Okutsu
 wrote:
> Hi Jonathan,
>
> The AIX specific code looks OK to me. But I'd suggest the code be moved to
> getPlatformTimeZoneID() for AIX, which just returns NULL currently. Also
> there's a function for producing a fallback ID in "GMT±hh:mm",
> getGMTOffsetID() which can be called in tzerr.
>
> Thanks,
> Masayoshi
>
>
> On 3/26/2014 3:47 PM, Jonathan Lu wrote:
>>
>> Hi ppc-aix-port-dev, core-libs-dev,
>>
>> Here's a patch for JDK-8034220,
>>
>> http://cr.openjdk.java.net/~luchsh/JDK-8034220/
>>
>> It is trying to add the a more complete timezone mapping mechanism for AIX
>> platform.
>> the changes are primarily based on IBM's commercial JDK code, which
>> includes:
>>
>> - A new timezone mapping file added under directory jdk/src/aix/lib/
>> - Code to parse above config file, changed file is
>> src/solaris/native/java/util/TimeZone_md.c
>> - And also makefile change in make/CopyFiles.gmk to copy the config file
>>
>> Could you pls help to review and give comments ?
>>
>> Cheers
>> - Jonathan
>
>

Re: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl

[Aleksej Efimov]

Lance,
The document implementation (DocumentImpl) returned by 
'builder.newDocument()' should implement org.w3c.dom.Node and 
org.w3c.dom.Document interfaces, but shouldn't have the 'getXmlVersion' 
method (in Node, Document and DocumentImpl) - it's a main item required 
by Apache bug. So it means, that we need to substitute all three classes 
(Document,Node and DocumentImpl). The test should be executed with JDKs 
Node, Document, but DocumentImpl should be compiled against incorrect 
interfaces. I don't see, how I can implement it with jtreg keywords (the 
main problem is splitting the compilation of DocumentImpl (fake Node, 
Document) and the test run (only fake DocumentImpl).


The only reason why StringBuffer is not used here - the process of how 
updates were moved from Xerces to JAXP: revision by revision. And I 
don't think that it should prevent us from replacing it with faster 
StringBuilder =). Will change it to StringBuilder.


Thank you,
Aleksej

On 03/26/2014 09:04 PM, Lance Andersen wrote:
Any reason not to use StringBuilder in place of StringBuffer 
in XMLEntityManager.java


other than the above and my question on the need of using run.sh, it is OK

On Mar 26, 2014, at 12:54 PM, Lance Andersen 
mailto:lance.ander...@oracle.com>> wrote:



Hi Aleksej,

Do you really need to use run.sh?  If possible it would be better to 
try and avoid providing a script and  use the jtreg keywords.


Best
Lance
On Mar 26, 2014, at 12:39 PM, Aleksej Efimov 
mailto:aleksej.efi...@oracle.com>> wrote:



Hello,

Can I ask for a review for the update of DOMSerializerImpl class [1] 
to the latest Apache Xerces implementation.

The following changes were made:
1. The DOMSerializerImpl update: The Xerces class was used as a base 
[2]; the  476047 and 473125 revisions from Xerces was excluded (they 
will be resolved as a part of JDK-8035467 - move to Xalan serializer 
bug); the jaxp 632 revision was applied to new version of this class.
2. The DOMSerializerImpl.java file was reformated, because of 
not-good formatting in original file from Apache repo [2].
3. Other changes related to the DOMSerializerImpl update were 
applied from Xerces repo to JDK(the full revisions list can be found 
in the JBS [1]).
4. All license headers were updated to the latest version of Apache 
header in modified files.
5. New regression test was added to reproduce a problem described in 
Apache bug XERCESJ-1007 [3].


Webrevs for these changes:
http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp 

http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk 



Testing:
JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml 
xml_schema): pass

JTREG tests (javax/xml, jdk_other): pass

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-6339023
[2] 
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup

[3] https://issues.apache.org/jira/browse/XERCESJ-1007





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







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 [8038333] java/lang/ref/EarlyTimeout.java failed

[Mandy Chung]

Hi Ivan,

On 3/26/2014 6:15 AM, Ivan Gerasimov wrote:

Hello!

The test java/lang/ref/EarlyTimeout.java, which has been recently 
added to the repository with the fix for 6853696 has failed.
The error message of the failure "more than one references were 
removed from queue" seems to be misguiding.


I suspect that the real cause of the failure could have been that both 
child thread failed to get the reference during the specified timeout.

Thus, nonNullRefCount may have been zero and not some value > 1.



Are you able to reproduce the test failure?  I think the test verifies 
that only one thread gets the reference is a good test.


I think the race is due to the threads get to call queue.remove as soon 
as both threads decrement the count of the latch that can be well before 
the reference is enqueued.


It'd be good to add additional information in the test to help 
diagnosing test failure.


Mandy


Here's the trivial fix:
http://cr.openjdk.java.net/~igerasim/8038333/0/webrev/

Sincerely yours,
Ivan Gerasimov

Re: RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl

[Lance Andersen]

Any reason not to use StringBuilder in place of StringBuffer in 
XMLEntityManager.java

other than the above and my question on the need of using run.sh, it is OK

On Mar 26, 2014, at 12:54 PM, Lance Andersen  wrote:

> Hi Aleksej,
> 
> Do you really need to use run.sh?  If possible it would be better to try and 
> avoid providing a script and  use the jtreg keywords.
> 
> Best
> Lance
> On Mar 26, 2014, at 12:39 PM, Aleksej Efimov  
> wrote:
> 
>> Hello,
>> 
>> Can I ask for a review for the update of DOMSerializerImpl class [1] to the 
>> latest Apache Xerces implementation.
>> The following changes were made:
>> 1. The DOMSerializerImpl update: The Xerces class was used as a base [2]; 
>> the  476047 and 473125 revisions from Xerces was excluded (they will be 
>> resolved as a part of JDK-8035467 - move to Xalan serializer bug); the jaxp 
>> 632 revision was applied to new version of this class.
>> 2. The DOMSerializerImpl.java file was reformated, because of not-good 
>> formatting in original file from Apache repo [2].
>> 3. Other changes related to the DOMSerializerImpl update were applied from 
>> Xerces repo to JDK(the full revisions list can be found in the JBS [1]).
>> 4. All license headers were updated to the latest version of Apache header 
>> in modified files.
>> 5. New regression test was added to reproduce a problem described in Apache 
>> bug XERCESJ-1007 [3].
>> 
>> Webrevs for these changes:
>>   http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp
>>   http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk
>> 
>> Testing:
>> JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml xml_schema): pass
>> JTREG tests (javax/xml, jdk_other): pass
>> 
>> Thank you,
>> Aleksej
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-6339023
>> [2] 
>> http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup
>> [3] https://issues.apache.org/jira/browse/XERCESJ-1007
>> 
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> lance.ander...@oracle.com
> 
> 
> 



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 (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl

[Lance Andersen]

Hi Aleksej,

Do you really need to use run.sh?  If possible it would be better to try and 
avoid providing a script and  use the jtreg keywords.

Best
Lance
On Mar 26, 2014, at 12:39 PM, Aleksej Efimov  wrote:

> Hello,
> 
> Can I ask for a review for the update of DOMSerializerImpl class [1] to the 
> latest Apache Xerces implementation.
> The following changes were made:
> 1. The DOMSerializerImpl update: The Xerces class was used as a base [2]; the 
>  476047 and 473125 revisions from Xerces was excluded (they will be resolved 
> as a part of JDK-8035467 - move to Xalan serializer bug); the jaxp 632 
> revision was applied to new version of this class.
> 2. The DOMSerializerImpl.java file was reformated, because of not-good 
> formatting in original file from Apache repo [2].
> 3. Other changes related to the DOMSerializerImpl update were applied from 
> Xerces repo to JDK(the full revisions list can be found in the JBS [1]).
> 4. All license headers were updated to the latest version of Apache header in 
> modified files.
> 5. New regression test was added to reproduce a problem described in Apache 
> bug XERCESJ-1007 [3].
> 
> Webrevs for these changes:
>http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp
>http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk
> 
> Testing:
> JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml xml_schema): pass
> JTREG tests (javax/xml, jdk_other): pass
> 
> Thank you,
> Aleksej
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-6339023
> [2] 
> http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup
> [3] https://issues.apache.org/jira/browse/XERCESJ-1007
> 



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

RFR (JAXP): 8035437: Xerces Update: xml/serialize/DOMSerializerImpl

[Aleksej Efimov]

Hello,

Can I ask for a review for the update of DOMSerializerImpl class [1] to 
the latest Apache Xerces implementation.

The following changes were made:
1. The DOMSerializerImpl update: The Xerces class was used as a base 
[2]; the  476047 and 473125 revisions from Xerces was excluded (they 
will be resolved as a part of JDK-8035467 - move to Xalan serializer 
bug); the jaxp 632 revision was applied to new version of this class.
2. The DOMSerializerImpl.java file was reformated, because of not-good 
formatting in original file from Apache repo [2].
3. Other changes related to the DOMSerializerImpl update were applied 
from Xerces repo to JDK(the full revisions list can be found in the JBS 
[1]).
4. All license headers were updated to the latest version of Apache 
header in modified files.
5. New regression test was added to reproduce a problem described in 
Apache bug XERCESJ-1007 [3].


Webrevs for these changes:
http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jaxp
http://cr.openjdk.java.net/~aefimov/8035437/webrev.00/jdk

Testing:
JCK tests (api/xsl api/xinclude api/javax_xml api/org_xml xml_schema): pass
JTREG tests (javax/xml, jdk_other): pass

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-6339023
[2] 
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xml/serialize/DOMSerializerImpl.java?revision=944789&view=markup

[3] https://issues.apache.org/jira/browse/XERCESJ-1007

Re: Implicit 'this' return for void methods

[Paul Benedict]

It would be nice to make this language change. In the past years, it's
pretty clear many JSR EE spec leads have gone on to make their APIs return
the same object because they strongly prefer to see object chaining in
code. I sympathize with those designers, but I don't agree; I wouldn't
affect my API just for the sake of chaining. For the sake of clarity, I
prefer functions that don't compute anything to return void. So +1 for the
language to figure this out.


On Wed, Mar 26, 2014 at 10:51 AM, Guy Steele  wrote:

>
> On Mar 26, 2014, at 4:17 AM, Ulf Zibis  wrote:
>
> > See also:
> > . . .
> > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html
>
> This last one has a specific proposal, which is simple and quite nice.
>  The important idea is
> that we don't actually make any change to the code of void methods or make
> them actually
> return anything; instead, the caller takes notice of situations where an
> invocation of
> a void method is used as a subexpression whose value is required
> (heretofore forbidden
> by the language) and gives it a special interpretation.
>
> I note that Ulf's proposal applies only to method invocations, but I note
> that the same
> technique could be used to include field references if desired.
>
> I am wholeheartedly in favor of allowing "chaining" of dotted expressions
> such as
>
>CharBuffer.allocate(26).position(2).put("C").position(25).put("Z")
>
> I am a bit more skeptical about expressions that begin with a dot because
> of potential
> confusion about which expression is referred to:
>
> myVeryLongNamedString.subString(.indexOf("C"), .indexOf("Q"))
>
> seems clear enough, but what about:
>
> myVeryLongNamedString.subString(.indexOf("C") + otherString.length(),
> .indexOf("Q"))
>
> Does the second occurrence of .indexOf use myVeryLongNamedString or
> otherString?
>
> A compromise would be to allow leading-dot expressions to occur only
> within the arguments
> of the method call whose target is the object which the leading-dot
> expressions are expected
> to use as their target, and if there are such leading-dot expressions
> within the arguments
> then the arguments must not contain any non-leading-dot field references
> or method calls.
> Just a thought for discussion.  This would be considered a separate
> mechanism from the
> chaining-of-void-methods mechanism (it was a very clever idea to try to
> unify them in Ulf's
> original proposal, though).
>
> --Guy
>
>


-- 
Cheers,
Paul

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

[Alan Bateman]

On 26/03/2014 15:19, Peter Levart wrote:
I couldn't find any official document about possible os.name values 
for different supported OSes. Does anyone have a pointer?
I don't know if there is a definite list but I assume we don't need to 
be concerned with anything beyond the 4 that we have in OpenJDK, which 
is "Linux", "SunOS", "AIX" and contains("OS X").


If we get to the point in JDK 9 where src/solaris is renamed to src/unix 
(or something equivalent) then it could mean that the Os enum can be 
replaced with an OS specific class in src/linux, src/solaris, ... and 
this would avoid the need for an os.name check at runtime.


-Alan.

Re: Implicit 'this' return for void methods

[Guy Steele]

On Mar 26, 2014, at 4:17 AM, Ulf Zibis  wrote:

> See also:
> . . .
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html

This last one has a specific proposal, which is simple and quite nice.  The 
important idea is
that we don’t actually make any change to the code of void methods or make them 
actually
return anything; instead, the caller takes notice of situations where an 
invocation of
a void method is used as a subexpression whose value is required (heretofore 
forbidden
by the language) and gives it a special interpretation.

I note that Ulf’s proposal applies only to method invocations, but I note that 
the same
technique could be used to include field references if desired.

I am wholeheartedly in favor of allowing “chaining” of dotted expressions such 
as

   CharBuffer.allocate(26).position(2).put("C").position(25).put("Z”)

I am a bit more skeptical about expressions that begin with a dot because of 
potential
confusion about which expression is referred to:

myVeryLongNamedString.subString(.indexOf("C”), .indexOf("Q”))

seems clear enough, but what about:

myVeryLongNamedString.subString(.indexOf("C”) + otherString.length(), 
.indexOf("Q”))

Does the second occurrence of .indexOf use myVeryLongNamedString or otherString?

A compromise would be to allow leading-dot expressions to occur only within the 
arguments
of the method call whose target is the object which the leading-dot expressions 
are expected
to use as their target, and if there are such leading-dot expressions within 
the arguments
then the arguments must not contain any non-leading-dot field references or 
method calls.
Just a thought for discussion.  This would be considered a separate mechanism 
from the
chaining-of-void-methods mechanism (it was a very clever idea to try to unify 
them in Ulf's
original proposal, though).

—Guy

RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

[Peter Levart]

Hi,

This is a preview of the effort to merge all 4 variants of UNIXProcess 
class into one source. Here's the bug:


https://bugs.openjdk.java.net/browse/JDK-8000975

And here's the webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/UNIXProcess/webrev.02/

Per Alan's suggestion I have made the merged source (UNIXProcess.java) 
be a descendant of UNIXProcess.java.linux in mercurial history. This 
webrev also incorporates reaper thread pool changes for Solaris variant 
(this was the only variant not yet using thread pool) so that the 
changes are even simpler. Still missing is UNIX OS resolving based on 
os.name system property (Os.get() method). I couldn't find any official 
document about possible os.name values for different supported OSes. 
Does anyone have a pointer?


Regards, Peter

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

[Vladimir Ivanov]

Here's a version with the new naming scheme:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03.naming

I like existing naming scheme and OBJECT/VOID/LONG/etc names are quite 
popular(e.g. Wrapper & ASM (Opcodes) use them). So, I'm in favor of 
leaving it as is.


Best regards,
Vladimir Ivanov

On 3/26/14 12:24 AM, Christian Thalinger wrote:

+ enum BasicType {
+ L_TYPE('L', Object.class, Wrapper.OBJECT),  // all reference types
+ I_TYPE('I', int.class,Wrapper.INT),
+ J_TYPE('J', long.class,   Wrapper.LONG),
+ F_TYPE('F', float.class,  Wrapper.FLOAT),
+ D_TYPE('D', double.class, Wrapper.DOUBLE),  // all primitive types
+ V_TYPE('V', void.class,   Wrapper.VOID);// not valid in all 
contexts

I would suggest to not name them X_TYPE but give them meaningful names like 
Int, Float, Void.  The enum BasicType already infers that it’s a type.  If you 
think it’s not clear that it’s a type just use BasicType.Double in that places.

On Mar 24, 2014, at 9:29 AM, Vladimir Ivanov  
wrote:


Updated version:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/

- changed the way how arrays of types are created:
static final BasicType[] ALL_TYPES = BasicType.values();
static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, 
ALL_TYPES.length-1);

- added a test for BasicType (LambdaFormTest.testBasicType).

Best regards,
Vladimir Ivanov

On 3/22/14 2:08 AM, Vladimir Ivanov wrote:

John, thanks for the feedback.

Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02

Also moved LambdaForm.testShortenSignature() into a stand-alone unit test.

Best regards,
Vladimir Ivanov

On 3/21/14 10:54 PM, John Rose wrote:

On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov
mailto:vladimir.x.iva...@oracle.com>>
wrote:


Thanks for the feedback.

What do you think about the following:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/


That looks nice.  Strong typing; who woulda' thunk it.  :-)

The uses of ".ordinal()" are the extra cost relative to using just small
integers.  They seem totally reasonable in the code.

I suggest either wrapping "ordinal" as something like "id" or else
changing temp names like "id" to "ord", to reinforce the use of a common
name.

Don't make the enum class public.  And especially don't make the mutable
arrays public:

+public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE,
J_TYPE, F_TYPE, D_TYPE, V_TYPE };
+public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE,
J_TYPE, F_TYPE, D_TYPE };

— John

P.S.  That would only be safe if we had (what we don't yet) a notion of
frozen arrays like:

+public static final BasicType final[] ALL_TYPES = { L_TYPE,
I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE };
+public static final BasicType final[] ARG_TYPES = { L_TYPE,
I_TYPE, J_TYPE, F_TYPE, D_TYPE };



___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

RFR [8038333] java/lang/ref/EarlyTimeout.java failed

[Ivan Gerasimov]

Hello!

The test java/lang/ref/EarlyTimeout.java, which has been recently added 
to the repository with the fix for 6853696 has failed.
The error message of the failure "more than one references were removed 
from queue" seems to be misguiding.


I suspect that the real cause of the failure could have been that both 
child thread failed to get the reference during the specified timeout.

Thus, nonNullRefCount may have been zero and not some value > 1.

Here's the trivial fix:
http://cr.openjdk.java.net/~igerasim/8038333/0/webrev/

Sincerely yours,
Ivan Gerasimov

Re: Improve timezone mapping for AIX platform

[Masayoshi Okutsu]

Hi Jonathan,

The AIX specific code looks OK to me. But I'd suggest the code be moved 
to getPlatformTimeZoneID() for AIX, which just returns NULL currently. 
Also there's a function for producing a fallback ID in "GMT±hh:mm", 
getGMTOffsetID() which can be called in tzerr.


Thanks,
Masayoshi

On 3/26/2014 3:47 PM, Jonathan Lu wrote:

Hi ppc-aix-port-dev, core-libs-dev,

Here's a patch for JDK-8034220,

http://cr.openjdk.java.net/~luchsh/JDK-8034220/

It is trying to add the a more complete timezone mapping mechanism for AIX
platform.
the changes are primarily based on IBM's commercial JDK code, which
includes:

- A new timezone mapping file added under directory jdk/src/aix/lib/
- Code to parse above config file, changed file is
src/solaris/native/java/util/TimeZone_md.c
- And also makefile change in make/CopyFiles.gmk to copy the config file

Could you pls help to review and give comments ?

Cheers
- Jonathan

Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

[Paul Sandoz]

On Mar 26, 2014, at 5:21 AM, David Holmes  wrote:

> Mike,
> 
> On 26/03/2014 6:37 AM, Mike Duigou wrote:
>> Hello all;
>> 
>> Recently HotSpot gained additional support for transactional memory, 
>> . This patch is a 
>> libraries followon to that change. RTM and other transactional memory 
>> implementations benefit from clustering writes towards the end of the 
>> transaction whenever possible. This change optimizes the behaviour of two 
>> collection classes, Hashtable and Vector by moving several field updates to 
>> cluster them together near the end of the transaction. Yes, we know, these 
>> are obsolete collections but these two classes were used as the basis for 
>> the original benchmarking and evaluation during the development of the 
>> transactional memory JVM features. Future changes providing similar 
>> optimizations to other collections will be pursued when it can be shown they 
>> offer value and don't add a cost to non TM performance (TM is not yet a 
>> mainstream feature).
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8020860
>> http://cr.openjdk.java.net/~mduigou/JDK-8020860/0/webrev/
>> 
>> It is not expected that this change will have any meaningful impact upon 
>> performance (either positive or negative) outside of TM-enabled 
>> configurations. The main change is to move existing field updates towards 
>> the end of the transaction and avoid conditionals between field updates.
>> 
>> There is a slight behaviour change introduced in this changeset. Previously 
>> some methods updated the modcount unconditionally updated even when an 
>> ArrayIndexOutOfBoundsException was subsequently thrown for an invalid index 
>> and the Vector was not modified. With this change the modcount will only be 
>> updated if the Vector is actually changed. It is not expected that 
>> applications will have relied or should have relied on this behaviour.
> 
> I could live with that change in behaviour, but this change completely breaks 
> the fail-fast semantics of the iterators in some cases! If you don't update 
> modCount until after the change is complete, the iterator may access the 
> updated state and not throw CME!.
> 

There is a possibility that a method could barf before the modCount is updated 
e.g. before the fix the modCount was aggressively updated, but now it is 
possible to say throw an exception and the modCount will not be updated (see 
addAll if the collection is null or the index is out of bounds).


> I think this change is misguided.
> 

I too share concerns about this. 

I would have hoped that the compiler (both javac and the runtime) might be able 
to automatically move code around to group writes. In the interim of getting 
such good compiler support i can understand the need for certain updates to 
improve performance. 

Do we have access to the perf results?

Paul.

Re: Implicit 'this' return for void methods

[Ulf Zibis]

See also:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001512.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001365.html
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html

-Ulf

Am 25.03.2014 21:19, schrieb Victor Polischuk:

Good day, everyone,

I have a question regarding a proposal I found some time ago: 
http://tech.puredanger.com/java7#chained.

In a word, it is all about replacing 'void' behavior to always return 'this' 
and I think for static methods it would be nice to return Class instance. I 
have not found any mentions in JEPs and just wonder if the idea is rejected or 
still somewhere in pipeline for Java 1.x. (or perhaps it is just waiting to be 
filed by someone in brand new JEP).

---
Regards,
Victor Polischuk

Re: Implicit 'this' return for void methods

[Ulf Zibis]

See:
https://bugs.openjdk.java.net/browse/JDK-6472931
https://bugs.openjdk.java.net/browse/JDK-6373386
https://bugs.openjdk.java.net/browse/JDK-6479372
https://bugs.openjdk.java.net/browse/JDK-4774077
https://bugs.openjdk.java.net/browse/JDK-6451131
https://bugs.openjdk.java.net/browse/JDK-5082736

-Ulf


Am 25.03.2014 21:19, schrieb Victor Polischuk:

Good day, everyone,

I have a question regarding a proposal I found some time ago: 
http://tech.puredanger.com/java7#chained.

In a word, it is all about replacing 'void' behavior to always return 'this' 
and I think for static methods it would be nice to return Class instance. I 
have not found any mentions in JEPs and just wonder if the idea is rejected or 
still somewhere in pipeline for Java 1.x. (or perhaps it is just waiting to be 
filed by someone in brand new JEP).

---
Regards,
Victor Polischuk

Re: Improve timezone mapping for AIX platform

[Alan Bateman]

Adding i18n-dev to the thread as i18n-dev is where the TZ code is 
maintained.


On 26/03/2014 06:47, Jonathan Lu wrote:

Hi ppc-aix-port-dev, core-libs-dev,

Here's a patch for JDK-8034220,

http://cr.openjdk.java.net/~luchsh/JDK-8034220/

It is trying to add the a more complete timezone mapping mechanism for AIX
platform.
the changes are primarily based on IBM's commercial JDK code, which
includes:

- A new timezone mapping file added under directory jdk/src/aix/lib/
- Code to parse above config file, changed file is
src/solaris/native/java/util/TimeZone_md.c
- And also makefile change in make/CopyFiles.gmk to copy the config file

Could you pls help to review and give comments ?

Cheers
- Jonathan