On 10/09/2015 12:01 AM, Andrew Haley wrote:
On 09/09/2015 02:55 PM, David M. Lloyd wrote:
On 09/09/2015 08:17 AM, Andrew Haley wrote:
On 09/09/2015 02:13 PM, David M. Lloyd wrote:
How would you hook into the safepoint to perform the unmapping? You'd
have to wait for all threads to arrive at s
Hi Roger,
If timeouts need to be used, I suggest rather than fixed values they be
adjusted according to the timeout factor being used in the test run.
Can some sort of repeated testing with exponential backout to a longer
timeout be used ? If the system is actually ready is a fraction of a
s
One more comment regarding the CME check.
2829 if (expectedCount != modCount) {
2830 throw new ConcurrentModificationException();
2831 }
While it definitely serves the purpose of "fail-fast", but given it's a
ordered/sequential
st
Hi Stuart,
Can't modCount be increased to negative in extreme case?
2705 if (expectedCount>= 0&& expectedCount != modCount) {
2706 throw new ConcurrentModificationException();
2707 }
It'd be better to initialize expectedCount to modCount in constrocutor?
On 9/9/15 2:32 PM, Stuart Marks wrote:
I'll change the occurrences of "pipeline execution" to "stream pipeline
execution" per your exchange with Paul. Looks like there are two such
occurrences in each of the tokens() and findAll() methods.
Er, three such occurrences.
Webrev: (final, I hope)
Hi,
Please review this update to extract the uid on from the owner of the
/proc/ file.
It should be more reliable than using the owner of the
/proc//cmdline file.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
Thanks, Roger
On 9/9/2015 12:56 PM, Roger Riggs wrote:
Hi
On 9/9/15 12:50 AM, Paul Sandoz wrote:
<< After stream execution completes, this scanner is left in an indeterminate state
and cannot be reused. >>
Ah, shame, which strongly suggests advising that the stream/scanner should
always be closed afterwards, regardless of whether it contains a res
Hi Volker,
Looks good.
Roger
On 9/9/2015 12:36 PM, Volker Simonis wrote:
Hi,
can somebody please review this trivial fix which simply adds the
missing "-client IGNORE" to jvm.cfg file for ppc64 to avoid test
failures when running the regression tests:
http://cr.openjdk.java.net/~simonis/web
I think I've managed to reasonably firmly establish that atomically
remapping memory is impossible on Windows based on various anecdotal
evidence found from searching around (particularly on Cygwin mailing
list archives).
Another possible option is to use other Windows memory management APIs
Hi Volker,
Thanks for the review and diagnosis.
Can opening /proc/pid be used as a fallback if the st_uid is zero or
is it worth the overhead of stat'ing /proc/pid always?
Thanks, Roger
On 9/9/2015 11:46 AM, Volker Simonis wrote:
Hi Roger,
I think your change looks good and it surely improv
Hi,
Please find below a candidate fix for:
8033661: readConfiguration does not cleanly reinitialize the
logging system
https://bugs.openjdk.java.net/browse/JDK-8033661
http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.00/
LogManager.readConfiguration() presents a number of flaw
Hi Peter,
the problem of your approach is that you rely on the GC and as the others have
said,
usually a MappedByteBuffer is used a long time so it goes to a region that is
not clean frequently by the GC (if cleaned at all)
so it requires a FullGC, and there is no real way to ask for a FullGC
On 09/09/15 17:54, Mark Sheppard wrote:
Hi Vyom,
yes, I believe the consensus is to proceed with the changes.
OK - I will be pushing them then.
best regards,
-- daniel
regards
Mark
On 09/09/2015 16:23, Vyom Tewari wrote:
Hi Mark,
Is it OK to go ahead with the patch as it is, or you
MutableCallSite.setTarget() also works that way in Hotspot, it goes to a safe
point to trash all assembly codes generated from methods that use an
invokedynamic that uses the target of the callsite.
Rémi
- Mail original -
> De: "Andrew Haley"
> À: core-libs-dev@openjdk.java.net
> Envoy
Hi,
can somebody please review this trivial fix which simply adds the
missing "-client IGNORE" to jvm.cfg file for ppc64 to avoid test
failures when running the regression tests:
http://cr.openjdk.java.net/~simonis/webrevs/2015/8135271/
https://bugs.openjdk.java.net/browse/JDK-8135271
Thank you
Hi,
> As I thought, the problem for some seems to be non-prompt unmapping of
> mapped address space held by otherwise unreachable mapped byte buffers.
> The mapped address space doesn't live in the Java heap and doesn't
> represent a heap memory pressure, so GC doesn't kick-in automatically
> when
> - you track the number of mapped buffers (or mapped address space) that you
> "know" is active in the application manually.
The problem is you really can't do it on a global, JVM-scale, Peter.
It's enough that the same JVM process starts two isolated class
loaders with Lucene in each and such ac
Hi,
> As I thought, the problem for some seems to be non-prompt unmapping of
> mapped address space held by otherwise unreachable mapped byte buffers.
> The mapped address space doesn't live in the Java heap and doesn't
> represent a heap memory pressure, so GC doesn't kick-in automatically
> when
Hi Vyom,
yes, I believe the consensus is to proceed with the changes.
regards
Mark
On 09/09/2015 16:23, Vyom Tewari wrote:
Hi Mark,
Is it OK to go ahead with the patch as it is, or you are expecting any
additional modification is required ?.
Thanks,
Vyom
On 9/8/2015 6:35 PM, Mark Shep
On 09/09/2015 04:56 PM, Dawid Weiss wrote:
I think it would be best to leave to the application to decide and
implement the tracking and also triggering GC at times when it approaches
the limit.
I disagree. The GC -- when and how it is triggered -- should be
transparent to the application. We
Hi Roger,
I think your change looks good and it surely improves the test
stability but I don't think it solves the problem in all cases.
I think this problem is caused by a (i.e. "zombie") process
(the spawned process lived too short and was already a zombie when the
info object was created). If
Hi Mark,
Is it OK to go ahead with the patch as it is, or you are expecting any
additional modification is required ?.
Thanks,
Vyom
On 9/8/2015 6:35 PM, Mark Sheppard wrote:
that's true, the documentation is a bit nebulous on this issue.
but the inference is that the file descriptors are in
> I think it would be best to leave to the application to decide and
> implement the tracking and also triggering GC at times when it approaches
> the limit.
I disagree. The GC -- when and how it is triggered -- should be
transparent to the application. We don't want to manage GC, we want to
(trul
On 09/09/2015 04:21 PM, Peter Levart wrote:
Hi Uwe,
As I thought, the problem for some seems to be non-prompt unmapping of
mapped address space held by otherwise unreachable mapped byte
buffers. The mapped address space doesn't live in the Java heap and
doesn't represent a heap memory press
Hi Roger,
the change looks good.
Thanks for fixing this issue.
Regards,
Volker
On Tue, Sep 8, 2015 at 11:34 PM, Roger Riggs wrote:
> Oops, Corrected links to webrev:
>
> On 9/8/2015 5:10 PM, Roger Riggs wrote:
>>
>> Please review this test fix.
>> The test assumes that the pathname of the comm
Hi Uwe,
As I thought, the problem for some seems to be non-prompt unmapping of
mapped address space held by otherwise unreachable mapped byte buffers.
The mapped address space doesn't live in the Java heap and doesn't
represent a heap memory pressure, so GC doesn't kick-in automatically
when
On 09/09/2015 02:55 PM, David M. Lloyd wrote:
> On 09/09/2015 08:17 AM, Andrew Haley wrote:
>> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
>>> How would you hook into the safepoint to perform the unmapping? You'd
>>> have to wait for all threads to arrive at safepoints, wouldn't you?
>>
>> Yes.
On 09/09/2015 08:17 AM, Andrew Haley wrote:
On 09/09/2015 02:13 PM, David M. Lloyd wrote:
How would you hook into the safepoint to perform the unmapping? You'd
have to wait for all threads to arrive at safepoints, wouldn't you?
Yes. That happens in the VM already, e.g. when we need to revoke
On 09/09/2015 02:13 PM, David M. Lloyd wrote:
> How would you hook into the safepoint to perform the unmapping? You'd
> have to wait for all threads to arrive at safepoints, wouldn't you?
Yes. That happens in the VM already, e.g. when we need to revoke the
bias of a lock. It's a well-establish
On 09/09/2015 08:06 AM, Andrew Haley wrote:
On 09/09/2015 01:58 PM, David M. Lloyd wrote:
On 09/09/2015 07:49 AM, Andrew Haley wrote:
On 09/09/2015 01:41 PM, David M. Lloyd wrote:
If the answer to both of these can be shown to be affirmative, then I
think there is a real viable solution which
On 09/09/2015 01:58 PM, David M. Lloyd wrote:
> On 09/09/2015 07:49 AM, Andrew Haley wrote:
>> On 09/09/2015 01:41 PM, David M. Lloyd wrote:
>>> If the answer to both of these can be shown to be affirmative, then I
>>> think there is a real viable solution which allows immediate release of
>>> back
On 09/09/2015 07:49 AM, Andrew Haley wrote:
On 09/09/2015 01:41 PM, David M. Lloyd wrote:
If the answer to both of these can be shown to be affirmative, then I
think there is a real viable solution which allows immediate release of
backing resources, with the address space being reclaimed by GC.
On 09/09/2015 01:46 PM, Mike Hearn wrote:
> I guess, although it's ugly, a system property could control whether the
> NIO implementation returns an ordinary MappedByteBuffer or a new subclass,
> the UnmappableMappedByteBuffer. HotSpot would then be responsible for
> removing the overhead of the vi
On 09/09/2015 01:41 PM, David M. Lloyd wrote:
> If the answer to both of these can be shown to be affirmative, then I
> think there is a real viable solution which allows immediate release of
> backing resources, with the address space being reclaimed by GC.
GC delays can be days if an object is
Thanks for the contribution, Uwe.
So far I think I like Andrew's suggestion of a guard page the most.
Unmapping the guard page boils down to a kind of thread-local variable
without the actual cost of reading anything (in theory). So by
write-protecting the guard page and then unmapping the file, a
On 09/09/2015 13:41, David M. Lloyd wrote:
If you have access to a Windows development environment, it seems to
me that you could help directly with the testing required to determine
a solution.
I think my proposed remapping approach will work, but it is contingent
on testing the following
If you have access to a Windows development environment, it seems to me
that you could help directly with the testing required to determine a
solution.
I think my proposed remapping approach will work, but it is contingent
on testing the following on Windows:
* Determine if it is possible to
Hi,
Dawid Weiss and I are both involved in the Apache Lucene project and we know
the problems with MappedByteBuffer and unmapping. Dawid already responded with
a source code link to our impl (which needs to use the hacky cleaner()
approach; also look at the heavy documentation in this class):
On 09/09/15 09:37, Paul Sandoz wrote:
On 9 Sep 2015, at 10:04, Chris Hegarty wrote:
<< After stream execution completes, this scanner is left in an indeterminate state
and cannot be reused. >>
I think this note is good, but the webrev/specdiff uses the term ‘pipeline
execution’. I think ‘s
On 09/08/2015 09:39 PM, Ulf Zibis wrote:
> Am 08.09.2015 um 20:37 schrieb Andrew Haley:
>> I think that MR is referring to Windows when he talks about race conditions.
>> Andrew.
>
> Couldn't we introduce a unmap() method which throws an
> UnsupportedOperationException if the
> underlying OS i
On 9 Sep 2015, at 10:04, Chris Hegarty wrote:
>>
>> << After stream execution completes, this scanner is left in an
>> indeterminate state and cannot be reused. >>
>
> I think this note is good, but the webrev/specdiff uses the term ‘pipeline
> execution’. I think ‘stream execution’ is less li
On 09/08/2015 08:15 PM, Remi Forax wrote:
> On 09/08/2015 03:29 PM, Andrew Haley wrote:
>> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>>> I don't think you'd actually need to unmap anything until a safepoint.
>>> I don't think that the speed of unmapping is critical as long as it
>>> happens "soon
This looks very nice, just a minor spec comment..
> On 9 Sep 2015, at 01:53, Stuart Marks wrote:
>
>
>
> On 9/4/15 1:35 AM, Paul Sandoz wrote:
>> Hi Stuart,
>>
>> This is looking very good.
>>
>> Just some comments on the tricky aspect related to late-binding of the
>> Stream to the scanner
Thanks Joe - pushed.
David
On 9/09/2015 2:42 PM, joe darcy wrote:
Approved; thanks David,
-Joe
On 9/8/2015 9:38 PM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8133611
Webrev: http://cr.openjdk.java.net/~dholmes/8133611/webrev/
Patch inline below.
Now the hotspot fix
On 9 Sep 2015, at 02:53, Stuart Marks wrote:
> I think the following covers all of the before, during, and after cases.
>
> << Scanning starts upon initiation of the terminal stream operation, using
> the current state of this scanner. Subsequent calls to any methods on this
> scanner other th
45 matches
Mail list logo
