that behavior was also fixed with
the condition ('&& pctx->state == IN_TOKEN') added by the patch.
On Thu, 2020-03-05 at 20:34 +0100, Robert Stupp wrote:
> Sorry for the broken formatting...
>
> I recently came across a bug in the java executable with an argfile
>
XXX
-Dfoo=bar
With the above change (the attached patch in argfile-parse-bug.txt),
argfile parsing works as expected.Also updated the condition in the
loop looking for a comment's newline, as it looks inconsistent to the
condition in the loop for FIND_NEXT/SKIP_LEAD_WS and the condition of
the out
Hi,
I recently came across a bug in the java executable with an argfile
that's larger than 4096 bytes, if a 4096-byte-chunk ends in a comment
line.
One bug happens when the last character of a comment line is the 4096th
byte and the trailing newline is the first byte in the next chunk. In
that case
aving an easier way to use different locations for
java.io.tmpdir instead of, for example, digging through build files and
inspecting command lines to check, whether surefire/junit/testng/JMH
passed the correct java.io.tmpdir properly to a spawned, maybe short
lived, child JVMs. WDYT?
Robert
--
Robert Stupp
@snazy
ue to build a similar functionality
using *Buffer.mismatch().
Robert
--
Robert Stupp
@snazy
() for all *Buffer classes.
Both new methods basically expose all the goodness of
jdk.internal.util.ArraysSupport to *Buffer.
The patch includes adoptions to the existing unit tests as well.
Robert
--
Robert Stupp
@snazy
# HG changeset patch
# User Robert Stupp
# Date 1524399060 -7200
# Sun
x27;t found any tests that validates the content of java.io.tmpdir.
Robert
--
Robert Stupp
@snazy
# HG changeset patch
# User Robert Stupp
# Date 1524398509 -7200
# Sun Apr 22 14:01:49 2018 +0200
# Branch use-TMPDIR-env-Linux
# Node ID 3f9f58a5d4049fcba8e5201e321bf71984
> Am 01.04.2015 um 13:48 schrieb Alan Bateman :
>
> On 01/04/2015 12:24, Robert Stupp wrote:
>> Is it because of pausing GC otherwise?
>>
> Yes, GC and also that a Socket write is a potentially blocking operation.
> Some VMs do have a way of pinning objects in th
Is it because of pausing GC otherwise?
> Am 01.04.2015 um 13:21 schrieb Robert Stupp :
>
> Hi,
>
> jdk/src/solaris/native/java/net/SocketOutputStream.c always copy data from
> the given byte[] to a temporary stack/heap buffer.
> Wouldn’t it be sufficient to just use a
Hi,
jdk/src/solaris/native/java/net/SocketOutputStream.c always copy data from the
given byte[] to a temporary stack/heap buffer.
Wouldn’t it be sufficient to just use a pointer into the byte[] and directly
call NET_Send with that pointer?
—
Robert Stupp
@snazy
fancy data structures could be possible (although there's
already some project that already does this).
Have to admit, that I've no real clue how expensive it is to enter or leave
such a "critical section".
—
Robert Stupp
@snazy
Would be nice to have some kind of "async" process I/O streaming.
And an event mechanism to receive notifications when the process terminates or
input is available from stdout/stderr.
> Am 25.03.2014 um 09:45 schrieb Kasper Nielsen :
>
> On Mon, Mar 24, 2014 at 10:11 PM, roger riggs wrote:
>
>>
Am 07.02.2014 um 23:29 schrieb Jeremy Manson :
> We have a patch for tracking method calls, too. It doesn't do callbacks on
> method invocation, but it does provide a list of method invocations. You can
> already do callbacks on method entry and exit with JVMTI, but it is
> expensive, which
Am 07.02.2014 um 22:41 schrieb Benedict Elliott Smith
:
>
> I'm quite excited about these changes, it looks like a great way to provide
> support outside of unsafe.
A great way to remove a lot of the Unsafe methods at all by providing their
functionality to the world :)
side, if you take this approach, you can't call back into Java
> from the JVM callbacks. This is because calling back into Java may require
> the JVM to come to a safepoint, which you can't do in the middle of
> allocation (which is where the callback would occur).
>
>
> -Sherman
>
> On 02/06/2014 02:50 PM, Robert Stupp wrote:
>>> >>> -Chris.
>> >>
>
Hi,
I looked into the UTF serialization and deserialization code - and compared it
a bit with the code behind "new String(byte[], Charset)",
"String.getBytes(Charset)".
Just to find something that can be safely reused in Object*Stream classes to
optimize String handling.
The first thing I noti
Hi,
I'm trying to trace/count object allocations - especially regarding the
ObjectIn/OutputStream stuff.
I know two API points: JVMTI and instrumentation. JVMTI fires an event for
nearly everything except allocations from bytecode - instrumentation allows to
transform bytecode (e.g. to issue a
Am 22.01.2014 um 17:33 schrieb "David M. Lloyd" :
> The concept of explicit deserialization constructors is interesting and is
> something I've explored a little bit in the context of JBoss Marshalling.
...
> The idea with a serialization-aware constructor is that each serializable
> class cons
Is there any documentation available which optimizations Hotspot can perform
and what "collecting a garbage" object costs?
I know that these are two completely different areas ;)
I was inspecting whether the following code
for (Object o : someArrayList) { ... }
would be faster than
for (i
I found another location in OOS code that might be an optimization point:
In java.io.ObjectOutputStream.BlockDataOutputStream#write(byte[], int, int,
boolean) the first lines look like this:
if (!(copy || blkmode)) { // write directly
drain();
Am 22.01.2014 um 17:33 schrieb "David M. Lloyd" :
> The concept of explicit deserialization constructors is interesting and is
> something I've explored a little bit in the context of JBoss Marshalling.
...
> The idea with a serialization-aware constructor is that each serializable
> class const
Hi,
I digged through the object serialization code and found some lines that could
be optimized to reduce the number of calls to System.arraycopy() and temporary
object allocations especially during string (de)serialization.
In short sentences the changes are:
ObjectInputStream:
- skip primitive
Hello,
many real business applications make intensive use of the collections api. I
have spend some time and tried to improve it a bit:
I've added a shared empty array instances to java.util.Arrays and use
Arrays.EMPTY_OBJECT_ARRAY where appropriate in collection classes and reduce
use of new j
Hi,
I'm trying to build openjdk8 on OSX 10.9 but it fails.
The first issue is that cc complains about "undefined symbols __FreeBSD__,
__OpenBSD__, __NetBSD".
I worked around that by changing the "#elif (symbol)" lines with #endif/#ifdef
lines.
The next flood of errors look very strange - it se
Hi,
I was wondering why the mostly allocated class in nearly all applications is
char[]. A deeper inspection showed that a lot of these char[] allocations are
"caused" by the code from java.lang.StringBuilder.toString(), which created a
copy of its internal char array. Most StringBuilder instan
Hi,
is it ok to optimize for-each-loop code generation for instances of
java.util.List that also implement java.util.RandomAccess by expanding to
List lst$ = listexpr;
int len$ = lst$.size();
for (int i$ = 0 ; i$ < len$ ; i$++) {
T loopvar = lst$.get(i$);
Hi,
the current implementation of java.util.UUID.fromName() and
java.util.UUID.toString() unnecessarily produce a lot of temporary objects.
Especially the fromName() method creates some instances of java.lang.Long and
indirectly via "name.split()" many Strings, an ArrayList, etc. UUID.toString(
28 matches
Mail list logo
