On Jun 8, 2009, at 10:27 AM, Alan Bateman wrote:
Guy Korland wrote:
Hi,
I found out that an RMI call might never return on network
disconnection and will not throw RemoteException as expected.
The scenario is very simple:
1. Find a remote stub (the stub should be behind a router).
2. Physic
Doug,
To have single-indirect access we need to read
key/value objects with the first array read.
This is because we cannot store int and object
in one array - there's no structures in java.
But this approach have a negative side:
we don't have stored hashcode to compare,
hence we need to directl
I broke down and finally created a "proper" webrev,
just like the good old days.
http://cr.openjdk.java.net/~martin/clone-exec/
Martin
On Tue, Jun 9, 2009 at 12:24, Martin Buchholz wrote:
>
> Patch updated on cr.openjdk.java.net.
>
> Martin
Following up some more...
I did some cleanup of the USE_CLONE vs. non-USE_CLONE
code and tested both of them (on Linux at least).
I took the liberty of removing the references to fork1,
since OpenJDK7 only supports Solaris10 going forward.
The main fork logic now looks like this:
{
#if USE_C
On Tue, Jun 9, 2009 at 09:28, Michael McMahon wrote:
> Martin Buchholz wrote:
>
>> In the old implementation, we used the strategy of
>> fork+mutate environ+execvp
>> and we got the traditional shell script semantics
>> from our use of execvp.
>> Since environ is now a global shared-with-parent va
Martin Buchholz wrote:
In the old implementation, we used the strategy of
fork+mutate environ+execvp
and we got the traditional shell script semantics
from our use of execvp.
Since environ is now a global shared-with-parent variable,
we can't mutate it any more, therefore can't use execvp,
and mu
On Tue, Jun 9, 2009 at 06:56, Michael McMahon wrote:
> Martin Buchholz wrote:
>
>>
>>
>>Also, I don't follow why we need the
>> execve_as_traditional_shell_script()
>>function. Can you explain the reason for that?
>>
>>
>> I think my comment for that function explains it fairly well.
>
Doug,
On Tue, Jun 9, 2009 at 4:09 PM, Doug Lea wrote:
> Alex Yakovlev wrote:
>
>> entrySet() iterator which is very expensive.
>>
>> Very big speedup would be to reuse Entry object,
>>
>
> We had originally done this in a few classes.
> The Iterator spec even allows it. However, most
> usages ig
Martin Buchholz wrote:
Also, I don't follow why we need the
execve_as_traditional_shell_script()
function. Can you explain the reason for that?
I think my comment for that function explains it fairly well.
/**
* Exec FILE as a traditional Bourne shell script (i.e. one without
Alex Yakovlev wrote:
entrySet() iterator which is very expensive.
Very big speedup would be to reuse Entry object,
We had originally done this in a few classes.
The Iterator spec even allows it. However, most
usages ignore that part of the spec, and it led
to a bunch of bug reports, so now all
Attached is an UPDATED patch for bug 4837946, (and others) for
implementing asymptotically faster algorithms for multiplication of
large numbers in the BigInteger class (which also improves the
performance of large numbers BigDecimal, etc.)
This patch slightly modifies the patch I sent before
11 matches
Mail list logo
