Re: JVMInit function call - where is it located the source?

[mr rupplin]

Ok, David.  Great, you did it.


From: David Holmes 
Sent: Tuesday, August 21, 2018 9:38:06 PM
To: mr rupplin; core-libs-dev@openjdk.java.net; Andrew Haley
Subject: Re: JVMInit function call - where is it located the source?

On 22/08/2018 11:02 AM, mr rupplin wrote:
> Quickly, where do we look?  I can't seem to find where the "javac" command is 
> called in the C interface.

javac is just the name of a executable launcher that is built.

See make/launcher/Launcher-jdk.compiler.gmk

> Where is the java code that runs the parser/compiler?  Ok, thanks gotta run 
> ably.

src/jdk.compiler/share/classes/com/sun/tools/javac

David

>
> /mr
>
> 
> From: mr rupplin 
> Sent: Tuesday, August 21, 2018 6:37:30 PM
> To: core-libs-dev@openjdk.java.net; Andrew Haley
> Subject: Re: JVMInit function call - where is it located the source?
>
> Thanks.
>
> Get Outlook for Android
>
> 
> From: Andrew Haley 
> Sent: Tuesday, August 21, 2018 12:32:20 PM
> To: mr rupplin; core-libs-dev@openjdk.java.net
> Subject: Re: JVMInit function call - where is it located the source?
>
> On 08/21/2018 05:21 PM, mr rupplin wrote:
>> Inside java.c there is a JLI_Launch which purports to be the launching or 
>> entry point for the JVM.  The last line shows:
>>
>>
>> return JVMInit(, threadStackSize, argc, argv, mode, what, ret);
>>
>>
>> This is given apparently as a function call that will return an int.  
>> However the include file java.h shows no source for this function.
>
>>   Where is it located?
>
> Couldn't you just look?
>
> src/java.base/unix/native/libjli/java_md_solinux.c:79
>
>> And finally where is the javac.c source file? I'm sure it's been here and 
>> now its lost. - ok
>
> It's part of the Java launcher, jexec.c. The easiest way to discover
> this stuff is to run javac in a real C++ debugger.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. 
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

Re: JVMInit function call - where is it located the source?

[David Holmes]

On 22/08/2018 11:02 AM, mr rupplin wrote:

Quickly, where do we look?  I can't seem to find where the "javac" command is 
called in the C interface.


javac is just the name of a executable launcher that is built.

See make/launcher/Launcher-jdk.compiler.gmk


Where is the java code that runs the parser/compiler?  Ok, thanks gotta run 
ably.


src/jdk.compiler/share/classes/com/sun/tools/javac

David



/mr


From: mr rupplin 
Sent: Tuesday, August 21, 2018 6:37:30 PM
To: core-libs-dev@openjdk.java.net; Andrew Haley
Subject: Re: JVMInit function call - where is it located the source?

Thanks.

Get Outlook for Android


From: Andrew Haley 
Sent: Tuesday, August 21, 2018 12:32:20 PM
To: mr rupplin; core-libs-dev@openjdk.java.net
Subject: Re: JVMInit function call - where is it located the source?

On 08/21/2018 05:21 PM, mr rupplin wrote:

Inside java.c there is a JLI_Launch which purports to be the launching or entry 
point for the JVM.  The last line shows:


return JVMInit(, threadStackSize, argc, argv, mode, what, ret);


This is given apparently as a function call that will return an int.  However 
the include file java.h shows no source for this function.



  Where is it located?


Couldn't you just look?

src/java.base/unix/native/libjli/java_md_solinux.c:79


And finally where is the javac.c source file? I'm sure it's been here and now 
its lost. - ok


It's part of the Java launcher, jexec.c. The easiest way to discover
this stuff is to run javac in a real C++ debugger.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: JVMInit function call - where is it located the source?

[mr rupplin]

Quickly, where do we look?  I can't seem to find where the "javac" command is 
called in the C interface.


Where is the java code that runs the parser/compiler?  Ok, thanks gotta run 
ably.


/mr


From: mr rupplin 
Sent: Tuesday, August 21, 2018 6:37:30 PM
To: core-libs-dev@openjdk.java.net; Andrew Haley
Subject: Re: JVMInit function call - where is it located the source?

Thanks.

Get Outlook for Android


From: Andrew Haley 
Sent: Tuesday, August 21, 2018 12:32:20 PM
To: mr rupplin; core-libs-dev@openjdk.java.net
Subject: Re: JVMInit function call - where is it located the source?

On 08/21/2018 05:21 PM, mr rupplin wrote:
> Inside java.c there is a JLI_Launch which purports to be the launching or 
> entry point for the JVM.  The last line shows:
>
>
> return JVMInit(, threadStackSize, argc, argv, mode, what, ret);
>
>
> This is given apparently as a function call that will return an int.  However 
> the include file java.h shows no source for this function.

>  Where is it located?

Couldn't you just look?

src/java.base/unix/native/libjli/java_md_solinux.c:79

> And finally where is the javac.c source file? I'm sure it's been here and now 
> its lost. - ok

It's part of the Java launcher, jexec.c. The easiest way to discover
this stuff is to run javac in a real C++ debugger.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: JVMInit function call - where is it located the source?

[mr rupplin]

Thanks.

Get Outlook for Android


From: Andrew Haley 
Sent: Tuesday, August 21, 2018 12:32:20 PM
To: mr rupplin; core-libs-dev@openjdk.java.net
Subject: Re: JVMInit function call - where is it located the source?

On 08/21/2018 05:21 PM, mr rupplin wrote:
> Inside java.c there is a JLI_Launch which purports to be the launching or 
> entry point for the JVM.  The last line shows:
>
>
> return JVMInit(, threadStackSize, argc, argv, mode, what, ret);
>
>
> This is given apparently as a function call that will return an int.  However 
> the include file java.h shows no source for this function.

>  Where is it located?

Couldn't you just look?

src/java.base/unix/native/libjli/java_md_solinux.c:79

> And finally where is the javac.c source file? I'm sure it's been here and now 
> its lost. - ok

It's part of the Java launcher, jexec.c. The easiest way to discover
this stuff is to run javac in a real C++ debugger.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR(JDK12/JAXP/java.xml) 8209615: ParseError in XMLEventReader on a valid input

[Joe Wang]

Thanks Lance!   Yes, the test for 8158619 passed, as did all other xml 
tests.


Best,
Joe

On 8/21/18, 12:01 PM, Lance Andersen wrote:

Hi Joe,

The change and test look fine.  I assume the test for 8158619 is still 
happy :-)


Best
lance


On Aug 21, 2018, at 2:17 PM, Joe Wang > wrote:


Hi,

Please review a patch for a regression that was introduced in JDK 9 
b147 by the patch for JDK-8158619[1]. Prior to JDK-8158619, the JDK 
parser returns all contiguous character data in a single chunk. After 
the patch then, the parser would return partially if the data is not 
read completely in the current buffer. Before it returns however, it 
should have maintained the state so that it could continue parsing as 
CDATA for the next read. What's missing in the JDK-8158619 therefore 
was to set the state explicitly to CDATA. Without doing so, the 
parser would attempt to read the beginning of the next buffer to 
determine the state, that sometimes (as in this case) could be wrong.


JBS: https://bugs.openjdk.java.net/browse/JDK-8209615
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/ 




[1] https://bugs.openjdk.java.net/browse/JDK-8158619

Thanks,
Joe





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(JDK12/JAXP/java.xml) 8209615: ParseError in XMLEventReader on a valid input

[Lance Andersen]

Hi Joe,

The change and test look fine.  I assume the test for 8158619 is still happy :-)

Best
lance


> On Aug 21, 2018, at 2:17 PM, Joe Wang  wrote:
> 
> Hi,
> 
> Please review a patch for a regression that was introduced in JDK 9 b147 by 
> the patch for JDK-8158619[1]. Prior to JDK-8158619, the JDK parser returns 
> all contiguous character data in a single chunk. After the patch then, the 
> parser would return partially if the data is not read completely in the 
> current buffer. Before it returns however, it should have maintained the 
> state so that it could continue parsing as CDATA for the next read. What's 
> missing in the JDK-8158619 therefore was to set the state explicitly to 
> CDATA. Without doing so, the parser would attempt to read the beginning of 
> the next buffer to determine the state, that sometimes (as in this case) 
> could be wrong.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8209615
> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8158619
> 
> Thanks,
> Joe
> 

 
  

 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(JDK12/JAXP/java.xml) 8209615: ParseError in XMLEventReader on a valid input

[Joe Wang]

Hi,

Please review a patch for a regression that was introduced in JDK 9 b147 
by the patch for JDK-8158619[1]. Prior to JDK-8158619, the JDK parser 
returns all contiguous character data in a single chunk. After the patch 
then, the parser would return partially if the data is not read 
completely in the current buffer. Before it returns however, it should 
have maintained the state so that it could continue parsing as CDATA for 
the next read. What's missing in the JDK-8158619 therefore was to set 
the state explicitly to CDATA. Without doing so, the parser would 
attempt to read the beginning of the next buffer to determine the state, 
that sometimes (as in this case) could be wrong.


JBS: https://bugs.openjdk.java.net/browse/JDK-8209615
webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/


[1] https://bugs.openjdk.java.net/browse/JDK-8158619

Thanks,
Joe

Re: RFR: JDK-8205461 Create Collector which merges results of two other collectors

[Stuart Marks]

On 8/21/18 12:04 AM, Peter Levart wrote:
 - UNORDERED: should the returned collector be UNORDERED if *either* of the 
provided collectors is UNORDERED? (Current draft says *both*.)


I think *both* is the right behavior. If you are collecting:

    teeingAndThen(
        Collectors.toList(),
        Collectors.toSet(),
        Map::entry
    )

...then you might want the returned List part of result to respect encounter 
order regardless of the returned Set part which doesn't.

OK, this makes sense. Seems like it should be "both" then.

s'marks

Re: JVMInit function call - where is it located the source?

[Andrew Haley]

On 08/21/2018 05:21 PM, mr rupplin wrote:
> Inside java.c there is a JLI_Launch which purports to be the launching or 
> entry point for the JVM.  The last line shows:
> 
> 
> return JVMInit(, threadStackSize, argc, argv, mode, what, ret);
> 
> 
> This is given apparently as a function call that will return an int.  However 
> the include file java.h shows no source for this function.

>  Where is it located?

Couldn't you just look?

src/java.base/unix/native/libjli/java_md_solinux.c:79

> And finally where is the javac.c source file? I'm sure it's been here and now 
> its lost. - ok

It's part of the Java launcher, jexec.c. The easiest way to discover
this stuff is to run javac in a real C++ debugger.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: JVMInit function call - where is it located the source?

[Aleksey Shipilev]

Hi,

I think you need to freshen up the search-fu: find, grep, and ack (beyondgrep). 
Without it, you
would find understanding the structure of any large project, OpenJDK included, 
quite frustrating.

On 08/21/2018 06:21 PM, mr rupplin wrote:
> This is given apparently as a function call that will return an int. However 
> the include
> filejava.h shows no source for this function. Where is it located?
[jdk-jdk] $ ack JVMInit src/
src/java.base/unix/native/libjli/java_md_solinux.c
791:JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
800:PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm)

src/java.base/macosx/native/libjli/java_md_macosx.c
885:JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
924:void PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm) {

src/java.base/windows/native/libjli/java_md.c
886:JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
895:PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm)

src/java.base/share/native/libjli/java.h
189:int JVMInit(InvocationFunctions* ifn, jlong threadStackSize,
202:void PostJVMInit(JNIEnv *env, jclass mainClass, JavaVM *vm);

src/java.base/share/native/libjli/java.c
341:return JVMInit(, threadStackSize, argc, argv, mode, what, ret);
529: * PostJVMInit uses the class name as the application name for GUI 
purposes,
535:PostJVMInit(env, appClass, vm);


> And finally where is the javac.c source file? I'm sure it's been here and now 
> its lost. - ok

[jdk-jdk] $ find src/ -name java.c
src/java.base/share/native/libjli/java.c

-Aleksey

Re: JVMInit function call - where is it located the source?

[Jonathan Gibbons]

On 8/21/18 9:21 AM, mr rupplin wrote:

Inside java.c there is a JLI_Launch which purports to be the launching or entry 
point for the JVM.  The last line shows:


return JVMInit(, threadStackSize, argc, argv, mode, what, ret);


This is given apparently as a function call that will return an int.  However 
the include file java.h shows no source for this function.  Where is it located?


--


And finally where is the javac.c source file? I'm sure it's been here and now 
its lost. - ok


max


Max,

grep is your friend. Try `grep -r JVMInit src`.

Re: javac.c source file.
You asked this before, on July 20, in an email with the subject line 
"Short Question - About javac.c where is it?".
It was answered back then by Erik Joelsson; I suggest you refer back to 
his answer.


-- Jon

JVMInit function call - where is it located the source?

[mr rupplin]

Inside java.c there is a JLI_Launch which purports to be the launching or entry 
point for the JVM.  The last line shows:


return JVMInit(, threadStackSize, argc, argv, mode, what, ret);


This is given apparently as a function call that will return an int.  However 
the include file java.h shows no source for this function.  Where is it located?


--


And finally where is the javac.c source file? I'm sure it's been here and now 
its lost. - ok


max

Re: Is returning a value != '0' or '1' as jboolean from a JNI function legal?

[Andrew Haley]

On 08/20/2018 08:25 PM, Jason Greene wrote:
> 
>> On Aug 20, 2018, at 12:23 PM, Andrew Haley  wrote:
>>
>> On 08/20/2018 04:14 PM, Jason Greene wrote:
>>
>>> IMO departing from C semantics (non-zero = TRUE, zero = false)
>>> offers little gain and will likely just lead to hard to catch
>>> bugs. Even if the JNI developer knows the rules, it will be quite
>>> easy for surprises to show up. For example, a developer might assume
>>> a library call always returns 1, and wire it straight to a
>>> boolean. If this assumption is broken (a condition not taken into
>>> account, or future behavioral differences), then it could quickly
>>> turn into a lot of wasted time and effort.
>>
>> It's tricky, though: a C implementation could silently truncate a
>> value of 0xff00_ to (jboolean) 0x00, and there's not a damn thing
>> that a JVM can do about it: there's literally no way to know.  It's
>> pretty much unfixable from our end.
> 
> OK but in that case the C developer can see its an unsigned char,

It's a jboolean.

> and their compiler is likely to throw an overflow warning.

Mmm, but GCC desn't.

> Granted, it’s also true that int is a more common return value than
> unsigned char.

The function in question is *defined* as returning a jboolean: there's
no doubt about that. The question is whether a C implementation
truncates return values, and you can only see that by reading the
system ABI specification. Not every system documents it: the only way
until recently to find out what GCC on x86 did was to look at the
generated code.

The system ABI is different on different systems: on AArch64 a
jboolean return value is silently truncated, on x86 it isn't. The only
solution is to do what's suggested: make sure that you return
JNI_TRUE/JNI_FALSE (or 1/0).

It's all too horrible even to think about.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR 8209064: Make intellij support more robust after changes for 2018.2

[Magnus Ihse Bursie]

Hi Maurizio!

Even if this only incidentally relates to the build, please always 
include build-dev when making changes in the "make" directory.


As far as I can understand, your changes looks good. One question: the 
build.xml was previously stored as a "template", and copied to the 
output directory. Now it's left in the source tree. I assume that there 
was no actual transformations or changes made to the template before? So 
that the scripts do not modify the source tree version, that is.


/Magnus

On 2018-08-07 13:21, Maurizio Cimadamore wrote:

Hi,
last week I submitted an 'emergency' patch to fix intellij project 
support after 2018.2 changes. The goal of these changes was to move 
the build.xml ant file out of the .idea folder, as the IDE no longer 
supported DOM indexing in such folders (as a result of 
https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I 
tweaked the scripts to copy build.xml in the build folder.


Thinking more about this issue, there's a more robust fix possible, 
which doesn't involve moving files to the build folder (which could be 
potentially unreliable, depending on how people build the JDK). In 
fact, the best solution is to leave build.xml where it is, and fix the 
remaining configuration files to point at it. This allows to revert 
all changes in the scripts that set up the project configuration 
(bin/idea.sh for JDK, and make/langtools/build.xml for langtools).


For the langtools project a bit more changes were necessary, given 
that in langtools we did not have a 'template' folder - and all 
intellij files were dumped onto the same path. So I had to move the 
configuration langtools files (all but build.xml) under a new template 
folder (located under make/langtools/intellij/make) and place 
build.xml outside it. Then tweak the build.xml script to work off this 
new template folder. These are all small conceptual changes, but the 
impact on the webrev is quite biggie (because of file renaming etc.).


I also took the chance to fix some issues with the JDK project ANT 
configuration (see changes in make/idea/template/workspace.xml), as 
the last changes did not update the location of the ant file used here 
- as a result no ant target entries were showing up under the Build menu.


Webrev here:

http://cr.openjdk.java.net/~mcimadamore/8209064/

Cheers
Maurizio

Re: RFR: JDK-8205461 Create Collector which merges results of two other collectors

[Peter Levart]

I just note that sometimes naming is hard. Not because there would be no 
suitable name to choose from but because there are too many. In such 
situations it becomes apparent that every individual's brain works 
slightly differently. That said, I must admit that teeingAndThen is not 
my favorite either. The "tee" UNIX command is not "symmetrical". It 
interposes itself into the pipeline as a pass-through element (stdin -> 
stdout) and has (one ore more) additional outputs in the form of files. 
The name "tee" comes from T-splitter used in plumbing, where the 
pass-through direction is a straight line (the horizontal on letter T), 
while the additional output is the vertical:


https://en.wikipedia.org/wiki/Piping_and_plumbing_fitting#Tee

Out collector is symmetrical though.

On 08/21/2018 07:43 AM, Stuart Marks wrote:
a few more names that (mostly) don't seem to have been proposed 
before, and so here they are for your consideration:


 - compound
 - composite
 - conjoined
 - bonded
 - fused
 - duplex

Discussion:

A "composite" evokes function composition; this might be good, though 
it might be odd in that collectors can't be composed in the same way 
that functions are.


"Compound" might be a useful alternative. In chemistry, two substances 
are combined (or bonded, or fused) to form a single substance, which 
is a compound.


"Conjoin" seems to adequately describe the structure of the two 
collectors, but it lacks somewhat the connotation of unifying them.


In an earlier discussion, Brian had pushed back on names related to 
split/fork/merge/join since those are currently in use in streams 
regarding splitting of input elements and merging of results. In 
describing how the current proposal differs, he said that elements are 
"multiplexed" to the different collectors. Since we're doing this with 
two collectors, how about "duplex"? (I note that Jacob Glickman also 
had suggested "duplex".) 


My brain likes "duplex".

duplex, duplexing or duplexingAndThen ? I think "duplexing". AndThen 
suffix is not needed. Even if there is a standard Pair class to come in 
the future, overloaded "duplexing" method could be added with no 
ambiguity (mental or javac).


Regards, Peter

Re: RFR: JDK-8205461 Create Collector which merges results of two other collectors

[Peter Levart]

Hi Stuart,

On 08/21/2018 07:43 AM, Stuart Marks wrote:

2. Characteristics

 - UNORDERED: should the returned collector be UNORDERED if *either* 
of the provided collectors is UNORDERED? (Current draft says *both*.)


I think *both* is the right behavior. If you are collecting:

    teeingAndThen(
        Collectors.toList(),
        Collectors.toSet(),
        Map::entry
    )

...then you might want the returned List part of result to respect 
encounter order regardless of the returned Set part which doesn't.



Regards, Peter