Also do you have any recommendations for deriving appropriate values for
Transport.MaxIdleConns
or Transport.MaxIdleConnsPerHost?
On Monday, August 20, 2018 at 12:59:07 AM UTC-7, golang...@gmail.com wrote:
>
> The http.Transport caches connections for future re-use
> https://golang.org/pkg/net/
There is no conservativeness to unsafe.Pointer. The type information for
any object in the heap is recorded at allocation time, and is unrelated to
the type of the reference currently held to it (be it unsafe.Pointer,
[]byte, *int64, or whatever).
So for 2.2, the answer is no, you are incorrect.
On Sun, Aug 19, 2018 at 9:39 PM, Amandeep Gautam
wrote:
> gmake[3]: Entering directory
> '/export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo'
> gmake[4]: Entering directory
> '/export/home/amandeep/gccgo-obj/sparc-sun-solaris2.10/libgo'
> /opt/csw/bin/gmkdir -p .; files=`echo
> /export/h
That information is old now - Go has a precise GC now. There is some sort
of metadata stored for each variable related to whether the type contains
pointers (as Jan alluded to earlier in the thread).
On Monday, August 20, 2018 at 7:28:51 AM UTC-7, Florian Uekermann wrote:
>
> From the GC POV, th
>
> From the GC POV, the only interesting thing about an unsafe.Pointer is if
> its value falls anywhere into a GC managed memory block for liveness
> analysis, AFAIK.
>
And then it will check that memory block for stuff that looks like a
pointer (not caring what the actual type being pointed t
On Mon, Aug 20, 2018 at 3:48 PM 'Florian Uekermann' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
>> The garbage collector does not care about the values of items of a []T
when T is not a pointer type nor a type containing transitively any
pointers.
>
> Just to make sure I understand you
>
> The garbage collector does not care about the values of items of a []T
> when T is not a pointer type nor a type containing transitively any
> pointers.
>
Just to make sure I understand you correctly. Are you saying I could hold
an unsafe.Pointer to an array of uint64 and the GC will still
On Mon, Aug 20, 2018 at 2:49 PM 'Florian Uekermann' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> ... which would put unnecessary strain on the GC iirc, because the memory
pointed to would be scanned conservatively (basically assuming everything
in there could be a pointer).
The garbag
Thanks Axel.
Good to know the first part. I have a couple of comments regarding your
answer to the second part.
In regards to your second question: That would require having an array type
> for every possible size, which isn't really tenable.
>
The idea was to use the same array type (`[(^uint
I'm not 100% sure, but… pretty sure? that the GC does not look at the
len/cap fields of slices. Reason being that that would require significant
alias-analysis, as two slices of the same underlying array can have
different lengths and capacities. So treating the underlying array not as
"one object"
Mistake in the second struct. The data field should have the type:
*[(^uint(0)) >> 17]uint64
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr
Dear all,
I have some questions concerning the implementation details of the garbage
collector regarding slices and arrays.
I'm implementing bit slices. The current approach is to use the following
struct:
type BitSlice {
data []uint64
len int
}
Given that the slices length and capacity are
That was it. Thanks!
On Saturday, August 18, 2018 at 10:27:25 PM UTC-4, rob.s...@team-rehab.com
wrote:
>
> Hi all! I'm hoping any of you could checkout my Golang question on Stack?
>
> https://stackoverflow.com/questions/51911363/passing-results-in-go-and-wxgo
>
> I really didn't know what to sea
It depends. For values (no pointers) that 40 may be slower to copy than the
dereference of the pointer. But pointers allow modifications, so the extra cost
may be balanced by the gained safety and less headache. And less nil pointers.
--
You received this message because you are subscribed to t
Thanks for confirming this is a regression.
On 20 August 2018 at 18:41, Shulhan wrote:
> On Sun, 19 Aug 2018 16:13:00 -0700 (PDT)
> Dave Cheney wrote:
>
>> Point of clarification, the package name doesn’t contain a dot, that
>> is not permitted by the syntax of the package declaration. The name
On Sun, 19 Aug 2018 16:13:00 -0700 (PDT)
Dave Cheney wrote:
> Point of clarification, the package name doesn’t contain a dot, that
> is not permitted by the syntax of the package declaration. The name
> of the directory you placed the file in ends in .go and this is
> confusing the tool.
>
Sor
The http.Transport caches connections for future re-use
https://golang.org/pkg/net/http/#Transport
Are requests sent serially by which I mean only one request and response
can be handled by this persistent connection at a time, so that other
concurrent requests to the same host are blocked until
17 matches
Mail list logo
